After every restart the changes I make to iptables are lost. I know now that I have to save the changes after making them, but every way of saving I tried so far doesn't work.
I tried the following :
/etc/init.d/iptables save (command not found)
/usr/libexec/iptables.init save (command not found)
/sbin/service iptables save (the service supports only basic lsb actions)
I'm just a basic *nix user, so most of my knowledge is based on uncle Google and I cannot find more solutions at the moment. Any help would be appreciated.
I'm on Fedora 22 64-bit.
As Fedora uses firewalld in recent versions, you need to do it with firewalld commands. Take a look here
If you insist to use iptables, you need to install iptables in order to use iptables-save and iptables-restore commands using dnf install iptables .
Related
as a first... yes...yes I know there are 1000 questions and solutions to this. But unfortunately none of them helps me.
Let's get to the problem:
I have a Docker container running on which MySQL is configured. Now I would like to change the bind address from 127.0.0.1 to 0.0.0.0. Unfortunately I can't open my.cnf because I don't have nano, vim installed. With apk, yum, vim, apt-get and so on I get that:
apt-get: command not found
apk: command not found
...
Could someone of you maybe help me out with my little problem?
best thanks and greetings
The default for MySQL docker image has been changed to Oracle based Linux distribution. In this distribution, the default package manager is yum. If for whatever reason you still want to use apt, pull Debian image explicitly. Something like mysql:8-debian.
See this issue for more detail.
You could do a docker cp to copy the file out of the container, edit it, and then docker cp it back in again. This may be fine if you need to do this for troubleshooting, but you probably want to look at fixing this in your deployment process. You should be able to destroy and re-create the docker container without having to manually fix configurations. This should be handled in your Dockerfile, or perhaps copying the correct configuration file in in your docker compose file.
I just installed CentOS 8 and added nodejs (tried v12 & v14) And then I installed pm2 using npm install pm2#latest (so at the time of posting it uses v4.4.0). I did try an older version (v3.5.0), but it does the exact same thing.
and after pm2 got installed, i ran the command "pm2 startup"
after a restart, pm2 does start, but gets killed after 90 seconds and then restarts giving this message
"pm2 has been killed by signal, dumping process list before exit..."
First, I thought it was because of my app (the one that pm2 is supposed to manage), but i removed it from pm2, so it's practically empty, but it does the same thing
Running the following command as root worked for me:
pm2 update
I had the same issue and I tried several solutions online but none worked for me.
However, I completely removed pm2, restarted the server, and reinstalled pm2 and that does it for me.
1- Stop and remove pm2
pm2 kill
sudo npm remove pm2 -g
2- Restart the server
sudo reboot
3- Log in again, then reinstall pm2
sudo npm install -g pm2
I did not disable SE Linux (I think it's not safe to disable it), but the following method helped me:
Edit file: /etc/systemd/system/pm2-root.service
Add new line: Environment=PM2_PID_FILE_PATH=/run/pm2.pid
And replace: PIDFile=/root/.pm2/pm2.pid to: PIDFile=/run/pm2.pid
Versions:
CentOS 8.3.2011
Node.js 14.16.0
NPM 7.7.5
PM2 4.5.5
Original answer. Thanks Alec!
Later update. For those who are facing the same issues. It's an issue related to SE Linux. Known workarounds (the ones I discovered).
Disabling SE Linux (obviously, not recommended)
go to /etc/systemd/system/pm2-root.service - comment PIDFile=... (add a # in front of that line)
Audit and trace - use following commands:
# dnf install policycoreutils-python-utils setroubleshoot-server -y
# journalctl -f
At ths point, you should see the solution in the output (the log)
it should be something like:
# ausearch -c 'systemd' --raw | audit2allow -M my-systemd
# semodule -i my-systemd.pp
You need to do the last step (ausearch... and semodule...) twice - I did it once, restarted the machine and noticed the same issue after 90 seconds. But if you read the log carefully, you will notice that the issue seems to be outputed twice. (looks the same). Probably two things are trying to write to that file (pm2-root.service).
Still waiting for the perfect solution (done by the person that really knows how to fix this in a proper manner), but for those that have this issue, any of these options seem to work just fine.
I've had this problem (on Debian), when for some reason two "PM2 God Daemon" processes (not threads) were launched, so they conflicting with each other.
Killing one of them solved the issue.
I'm trying to install a .deb file... for example:
example.deb.
But the program is already installed in an older version on the Debian minimal server.
So doing dpkg -i example.deb is creating a dialog, if i want to keep the configs...
is there any way to do this none interactive?
You can pipe yes into it:
yes | dpkg -i package.deb
man yes
You seem to be looking for
dpkg --force-confold -i package.deb
to specify that dpkg should prefer the existing, old configuration files in the case when there is a conflict.
More broadly, the proper solution depends on how desperate you are to avoid interactive prompts, and which prompts precisely you want to avoid.
dpkg has a number of options to select a particular behavior for various types of situations. Refer to its man page; scroll to the section on --force-things; one of them is --force-confold, or conversely --force-confnew to always replace any existing configuration file. (Many modern packages have a facility to upgrade any unchanged configurations completely automatically, but manually changed configuration files still require manual updating or merging.)
If you aren't running dpkg directly, apt and friends allow you to pass options to it with
apt install -o Dpkg::Options::="--force-confold" install package
(Yeah, that's a lot of colons. You probably want install -y to avoid interactive prompting by Apt itself, too.)
Setting the environment variable DEBIAN_FRONTEND to the string noninteractive will make Debconf (the configuration management component of Debian) select the default answer for all questions, and disable any prompting.
If the default answers to a package's configuration questions are not suitable, you can preseed Debconf's configuration database with the settings you want. You'll need to install debconf-utils which contains the utility debconf-set-selections. See further its man page and e.g. some sections of https://wiki.debian.org/DebianInstaller/Preseed (though this is rather focused en preseeding the installer, so you can potentially perform an unattended installation of all of Debian).
The problem with
yes | dpkg -i package.deb
is that you can't exactly predict which prompts are going to be shown, depending on the package's and the hosting system's configuration; you might say yes to something you didn't want to, or perhaps tell the system that your domain name or default database user is yes. Debconf was designed to give you very detailed and, for the most part, very safe and robust control over package installation - use that power.
I was doing some experiment on live migration using virsh. When I input anything related to tls, such as "# virsh -c qemu+tls://source/system",or "libvirtd --listen", there would be errors like "GNUTLS support not available in this build". So, here is what I tried to fix it:
Reinstall libvirt with --with-gnutls
#yum install gnutls-devel
#sh ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib64 --with-gnutls
After it successfully installed, reload it
# systemctl daemon-reload
# systemctl restart libvirtd
then I tried again my experiment, still there are errors "GNUTLS support not available in this build".
Any hints helpful will be appreciated sincerely.
Create TLS certificate first, follow the instruction on libvirt official website. Then reinstall libvirt again, everything goes right.
I use the Google Compute Engine Web Console to remote into my instance. I can perform root operations using "sudo", but what if I wanted to "su" to root?
I created a user "test", and now want to log-in as "test" -- this doesn't work as I have not yet generated SSH keys. Where do I find these keys for instance creator and/or root as well?
Also, I used a Debian image, but few commands appear to be installed by default. For instance, locate, updatedb, etc are missing? How do I get these?
You asked several questions in a single post; I'll answer them in order.
(1) I use the Google Compute Engine Web Console to remote into my instance. I can perform root operations using "sudo", but what if I wanted to "su" to root?
Use: sudo su -
(2) I created a user "test", and now want to log-in as "test" -- this doesn't work as I have not yet generated SSH keys. Where do I find these keys for instance creator and/or root as well?
You can ssh via gcloud compute ssh or by clicking on the "SSH" button on the web UI, and then run: sudo su test.
(3) Also, I used a Debian image, but few commands appear to be installed by default. For instance, locate, updatedb, etc are missing? How do I get these?
To install missing packages, you'll have to use the standard Debian command apt-get to install the packages, e.g.:
$ sudo apt-get install [name-of-package]
To find a package name using keywords, use:
$ apt-cache search [keyword]
Note: the first thing you want to do on a brand-new instance is to update your package metadata cache by running:
$ sudo apt-get update
https://cloud.google.com/solutions/set-up-postgres
The above link helped me get over a similar issue described above but in the postgres user setup context. Wasn't covered in any of the other posts so thought to share here.