icmp_echo_ignore_all doesn't get set - ping

I'm trying to set icmp_echo_ignore_all to 1, and I am able to do so using the following:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
I've also edited the sysctl.conf file and added:
net.ipv4.icmp_echo_ignore_all = 1
and then I followed with this:
sysctl -p
Supposedly the last two steps would permanently set icmp_echo_ignore_all to 1, until the next time I enable it. Every time I reboot, though, it goes back to 0. Am I missing a step? I'm doing it on a virtual machine running Ubuntu 14.04 LTS.
Any advice would be greatly appreciated.

For me this did only get set after I issued sysctl -w to set the setting, as opposed to editing sysctl.conf manually.
I found that most other settings in sysctl.conf are picked up on reboot as sysctl.conf is linked also as /etc/sysctl.d/99-sysctl.conf
For some reason this one isn't - or it is, but later in the boot process gets overwritten - so after a boot I usually manually issue sysctl -w again.

Related

libvirt qemu hook is not running

I am following what's suggested in this article to change the iptables rules in order to allow incoming connections. For some reason, the qemu hooks does not run. I simply tried to write into a file with echo 'some output' > someweirdfilename before making any vm name checks to run the actual script itself to later check the existence of the file. It looks like the hook is not executed at all. Made sure that libvirtd.service is restarted, so is guest and eventually tried the complete reboot. All resulted in the same. Running libvirt 7.6.0 on a fedora 35. Does anyone have any suggestions for troubleshooting?

Openshift Cronjob Not Running

I have tried to setup a simple cron job running on openshift but once I have pushed the file to openshift and then login and search for the file it does not seem to be there and there is not log output.
I created an application from: https://github.com/smarterclayton/openshift-go-cart
I then installed the cron 1.4 cartridge.
I created a file at .openshift/cron/minutely/awesome_job and set it as 755
I added the following contents:
#! /bin/bash
date > $OPENSHIFT_LOG_DIR/last_date_cron_ran
I pushed to the server
Logged in via ssh and run find /var/lib/openshift/53760892e0b8cdb5e9000b22 -name awesome_job for which it finds nothing.
Any ideas which might help as I am at loss why is it not working.
Make sure the execution bit is set on your cron file.
The issue was not with cron but with the golang cartridge I was using which was removing the .openshift directory.
https://github.com/smarterclayton/openshift-go-cart/issues/10
You should also put a file named "jobs.allow" under your .openshift/cron/minutely/. So your cron jobs will be executed.
For your ref: https://forums.openshift.com/daily-cron-jobs-not-getting-triggered-automatically
And the reason you can find your awesome_job vis ssh login is because it is under /var/lib/openshift/53760892e0b8cdb5e9000b22/app-root/runtime/repo/.openshift, so the command find does not search any files under folders named with . prefixed.

Cannot login to phpMyAdmin, no errors shown

I have MySQL set up correctly on my linux computer, however I want a better way to input data into the database besides terminal. For this reason, I downloaded phpMyAdmin. However, when I try to log in to the phpMyAdmin from index.php, it doesnt do anything. It seems to just refresh the page without doing anything. I am putting in the correct MySQL username and password. What is the issue?
Here is a screen shot of what it shows after I click "go".
This is a possible issue when the path to save php_session is not correctly set :
The directory for storing session does not exists or php do not have sufficient rights to write to it.
To define the php_session directory simply add the following line to the php.ini :
session.save_path="/tmp/php_session/"
And give write rights to the http server.
usually, the http server run as user daemon in group daemon. If it is the case, the following commands will make it :
chown -R :daemon /tmp/php_session
chmod -R g+wr /tmp/php_session
service httpd restart
Login fails if session folder in not writeable. To check that, create a PHP file in your web directory with:
<?php
$sessionPath = 'undefined';
if (!($sessionPath = ini_get('session.save_path'))) {
$sessionPath = isset($_ENV['TMP']) ? $_ENV['TMP'] : sys_get_temp_dir();
}
if (!is_writeable($sessionPath)) {
echo 'Session directory "'. $sessionPath . '"" is not writeable';
} else {
echo 'Session directory: "' . $sessionPath . '" is writeable';
}
If session folder is not writeable do either
sudo setfacl -R -m u:www-data:rwx <session directory> or chmod 777 sudo setfacl -R -m u:www-data:rwx <session directory>
-
I am late to the game, but on Amazon linux AMI I could not log in to phpmyadmin ... it just kept refreshing the login screen with no errors.
I have fixed with below command
sudo chmod -R 755 /var/lib/php/session
I fixed my issue on CentOS 7 with MariaDB and phpmyadmin I downloaded from offical phpmyadmin site by adding
session.save_path = "/var/lib/php/session"
to /etc/php.ini
and
chown -R :lighttpd /var/lib/php/session
I also restarted php-fpm and lighttpd after
In my case the solution was to set an Apache setting properly:
ProxyPassReverseCookiePath
This was required, because ProxyPass and ProxyPassReverse were in use, but cookie paths are not changed automatically.
It'd be great if PHPMyAdmin had shown something like session not found or anything, when password is sent with POST.
Do you have a .htaccess file in one of the parent directories that strips off index.php from the url by doing a 301 redirect?
301 redirects discard the form data and redirect you as if you didn't submit anything. So you get returned to the login page.
So you should create a local .htaccess file in the phpmyadmin directory with a single line RewriteEngine On. This will overwrite the previous rewrite rule to nothing.
You may need to clear the browser cache as Chrome aggressively caches 301 redirects.
In my case the hard drive was full.
Use df -h to check the space left on your hard drive, and if you want you can free some space by using the command sudo apt-get clean, which removes installation files.
I hope this will help some future users.
I ran these commands and it worked for me:
sudo service httpd restart
sudo service mysqld stop
sudo service mysqld start
Try searching the web for installation or setup guides for phpMyAdmin. Look at two or three of these and make sure you have covered all the required steps. (If you have already done so, please include which guides you have followed it in the question).
See if it helps to edit config.inc.php (acecoder mentioned this as well).
Check if this guide is of any help.
Which distro are you on? Try searching for the name of the distro you are using together with "phpMyAdmin guide" or "phpMyAdmin setup howto".
If you encounter errors along the way, post the error text here, if it's short (or paste via a pastebin-like site if it's long).
Are you sure that mysql is running? I had the same issue after doing a database import and filling up the volume containing the mysql database. After changing various permissions and clearing sessions, I tried to restart mysql (/etc/init.d/mysql restart) and it failed because the volume was full. After increasing /var and starting mysql successfully, I was able to log into phpmyadmin just fine.
If you have an error like:
Host 'host_name' is blocked because of many connection errors.
Login in your mysql as root and run the flush hosts command
1.- mysql -u root -p
2.- mysql > flush hosts
After this I was able to login again in phpmyadmin
phpMyAdmin will show errors when login fails. If it doesn't, it means that your setup has an error.
The most likely place to check is your php.ini settings. Since there doesn't seem to be an official list of phpMyAdmin-compatible settings, it's mostly trial and error.
Make sure you have enabled the stuff that needs to be enabled. Also check that you did not enable uncommon php.ini settings (like enable_post_data_reading = Off) because phpMyAdmin assumes them to be "the usual ones".
To ease debugging, start with a clean default php.ini file then tweak them line by line to see which setting is causing the error. (Don't forget that you need to restart your server after changing the php.ini file for the changes to take place.)
In my case it was due to an old Apache session.
Stop Apache, clear all pending sessions in your sessions.save_path directory (example: /var/lib/php/session) and restart Apache.
Make sure to set a 32 chars long random key in 'config.inc.php' in the $cfg['blowfish_secret'] value. That solved it for me.
Didn't realize I need to restart MariaDB after modifying config.inc.php:
service mariadb restart
Otherwise at least in my case changes didn't come affect. Also make sure your php session directory is writable by webserver (typically session.save_path = "/var/lib/php/session")

ipfw resetting after reboot

I added a rule in my ipfw a time ago and now I want to delete it. So i go:
sudo ipfw flush
And all user rules gets deleted. But everytime i restart the machine the rule is back again!
I tried looking for some ipfw config file, but has not find anything. When I added the rule the first time i user WaterRoof (frontend for ipfw), could that have somthing to do with this? (I also tried removing the rule with WaterRoof, but same result)
Any ideas on where this rule gets added every time? I don't know where to start.
Im running OS X 10.6
Hmpf... It was Internet Sharing that added the rule, when I turned it of it all went back to normal.
Should be the same for OSX. Run:
cat /etc/rc.conf |grep -i "firewall"
You should see:
firewall_script="/etc/ipfw.rules"
Modify whatever file that parameter is using.

How do you refresh the MySQL configuration file without restarting?

Apache has such a feature, what about MySQL?
Does one exist?
You were so close! The kill -HUP method wasn't working for me either.
You were calling:
select ##global.max_connections;
All you needed was to set instead of select:
set ##global.max_connections = 400;
See:
http://www.netadmintools.com/art573.html
http://www.electrictoolbox.com/update-max-connections-mysql/
Try:
sudo /etc/init.d/mysql reload
or
sudo /etc/init.d/mysql force-reload
That should initiate a reload of the configuration. Make sureyour init.d script supports it though, I don't know what version of MySQL/OS you are using?
My MySQL script contains the following:
'reload'|'force-reload')
log_daemon_msg "Reloading MySQL database server" "mysqld"
$MYADMIN reload
log_end_msg 0
;;
Reloading the configuration file (my.cnf) cannot be done without restarting the mysqld server.
FLUSH LOGS only rotates a few log files.
SET ##...=... sets it for anyone not yet logged in, but it will go away after the next restart. But that gives a clue... Do the SET, and change my.cnf; that way you are covered. Caveat: Not all settings can be performed via SET.
New with MySQL 8.0...
SET PERSIST ... will set the global setting and save it past restarts. Nearly all settings can be adjusted this way.
Specific actions you can do from SQL client and you don't need to restart anything:
SET GLOBAL log = 'ON';
FLUSH LOGS;