CentOS 7 have selinux activated, so when you decide to change your default httpd directories you have to give the right selinux permission to these directories otherwize the https server will not be able to access the files.
CentOs 7 have a built-in configuration to close the inactive ssh session. In term of security it is a good thing but when killing a session after 1 minute of inactivity start to be a mess when you have multiple session opened in parallel.
This can be avoid on the client side by configuring a keep-alive period on the client side. To activate a such keepalive, you just have to connect with the following command line:
ssh -o ServerAliveInterval=5 login@server.com
This will configure client to send a NULL packet every 5 seconds to keep the session opened.
If you try to access a remote database with nginx or httpd server, you will have a connection problem with error code (13) even if mysql/mariadb client works well in command line. The reason for that is a security limitation set by default not allowing httpd servers sur connect a remote DB.
To disable this limitation and make all work, just type in the command line :
# setsebool -P httpd_can_network_connect 1
You can list all the existing flags for httpd by using getsebool
# getsebool -a | grep httpd
In case you expect SELinux to be the cause of your problem, you can enable / disable it with the following functions
# setenforce 1 # setenforce 0
If you need to check what is the permission missing for SELinux you can run the audit
# tail -100 /var/log/audit/audit.log | audit2allow
Synology is providing a Glacier backup tool which seems to be an easy way to backup data on the low cost amazon solution. I will not describe how to configure it a log of blogs are doing it and I do not like to be redundant. The question I did not find an easy answer was : will I be able to restore my backup even if my synology crashed and I would not be able to get one other…
These two last days, I was participating to devoxx in Paris. One of the star topic of the event this year was Docker so I attempt different talk about this container technology I already has discovered in a previous JUG session. It was not an evidence that this technology was more than something interesting for DEV needing small, fast starting, small memory footprint, environment for testing. With my OPS hat, I did not catch the interest. This was before Devoxx and the different talk. The aspects I’ll detailed in this post have not been addressed during Devoxx, as much as I have seen, as mostly the DEV aspects have been addressed, I going to synthesize my opinion.
Since a couple of day at work I had to investigate on some network issues for an application, it seems that we have a strange ARP configuration that may be the main issue… by the way, I discovered another strange thing where icmp packets sent in burst mode (like a flood) are lost at variable rates. Here is the note on my investigations
It’s not the first time I have some trouble to setup grub2 correctly with my nvidia raid system (also called fake-raid) … I did not find exactly why, but for sure i never try to install grub2 correctly from yast or in manual mode.
The first solution to find was : how to boot a fresh installed system when the bootloader has not been configured. The solution is here : http://www.supergrubdisk.org. This tool is really simple and so efficient to boot ! I recommend to have this in your linux emergency kit !
The second solution, once the system has start is to reinstall a bootloader. Here, in fact the solution is easy : destroy this f**** grub2 and replace it by the legacy really good grub ! lol
Then it works … last step to me: understand why gnome is taking so long to start ?!? or the answer is in the question …
I love Linux !
