Posts tagged with “linux”

Fritz 7490: Root cause for Port mapping failure issue on a vagrant virtual machine

tl;dr

The root cause is that the default route was not set to the router's IP address.

My journey to resolve the issue:

The issue is that port mapping can work with my raspberry pi while it couldn't work with a virtual machine in the same LAN. I firstly think it must be a bug from the router. I upgrade the router to its latest firmware, but it still doesn't work. I google back and forth, I learned much from all kinds of answers, but they were just not my case. I almost decided to give up.

Then I found the following answer from E. van Putten, he answered this question and nobody gave his answer a "Like"!!!

In case you landed on this page because you can't reach a server running inside a Xen Guest from the internet (but can connect locally), then read on...

  1. The fritzbox can get confused by different OS'es appearing from the same MAC-address etc. (could happen while you are setting up / experimenting with Xen)
  2. The fritzbox has seemingly duplicate entries in the list, but with different settings, you need to delete the portmap from the incorrect entry, cleanup the list and reapply the portmap settings.
  3. It might be that your guest OS has no default gateway IP-address set. You'd expect a default gateway set to the local IP-address of your fritzbox. The symptoms of a missing default gateway is that your LAN PCs can access the server running inside the guest just fine, but external users from the internet cannot connect.

He gave three possible causes, and my case is the third one! here's my solution

opts = {
    :name => "yt-gateway",
    :ip => "192.168.178.173",
    :mem => "1024",
    :cpu => "1"
}
Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-20.04"
  config.vm.hostname = opts[:name]
  config.vm.network :public_network, ip: opts[:ip], bridge: "eno1"
  config.vm.provision "shell", run: "always", inline: "route add default gw 192.168.178.1 || true"
  config.vm.provider "virtualbox" do |v|
    v.name = opts[:name]
    v.customize ["modifyvm", :id, "--memory", opts[:mem]]
    v.customize ["modifyvm", :id, "--cpus", opts[:cpu]]
    v.customize ["modifyvm", :id, "--name", opts[:name]]
  end
end

I love you E. van!

Don't simple unset them afterward when using `shopt` change a setting

Sometimes we need to run shopt -s dotglob nullglob before moving files including dotfiles. So there's another question, do we need to set it back afterward? The most correct answer is

It's usually not clear if either dotglob or nullglob were already set before running shopt -s to set them. Thus, blindly un-setting them may not be the proper reset to do. Setting them in a subshell would leave the current shell's settings unchanged:

( shopt -s dotglob nullglob; mv ~/public/* ~/public_html/ )

Reference: Jeff Schaller's answer under this question

fameshot: a better screenshot tool with editing support for ubuntu

flameshot.png

Note: recover from accidentally changed the ownership of `sudo` command

Cause:

This morning, I change to the /backup directory and found I cannot write in it. So I rapidly typed sudo chown -R david:david .. then press Enter. You know what happened! All the files in / directory were changing the owner to me! I realized this by seeing an error message like "You cannot change the owner of xxx file to david".

Damn, how silly I was! Unfortunately, that was not the end of my bad luck. When I try to revert it by typing sudo chown -R root:root /, I got another error message: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set. Then I tried su - root but it seems that I haven't set a root password.

How can I recover my pop! OS?

  1. reboot it into single-user mode, edit the boot menu, add systemd.unit=rescue.target at the end of the boot line.
  2. In the boot console, chown -R root:root /usr; chmod 4755 /usr/bin/{sudo,dpkg,pkexec,crontab}; reboot

Rather easy, right? It did cost me over 10mins! PS. I met many issues later after recovering from the accident. One of them is that the crontab command did not work as usual. I have to run the instruction below to fix it.

sudo apt reinstall cron

Linux is also fragile, please don't be such silly thing next time. I told myself. PS: This time I also set a root password as well, so next time I could run su - root directly instead of going to the single user mode.

Fix the ‘Too Many Open Files’ Error in a systemd service in Linux

In short:

Change the service file, and add two lines after [Service] line,

[Service]
LimitNOFILE=65535
LimitNOFILESoft=65535

If you want to know more, read the Reference