If you’re after the patches themselves, you can download them directly: ![]() The awstats package I’ve built includes these two patches and also pulls in a current copy of MaxMind’s GeoIP database and required dependencies, so you’re all good to go immediately. I’ve built packages for CentOS/RHEL/etc 5 & 6, which are available at my repositories at. To fix this, I’ve written a patch for adding Yum user agent support and also merged in a patch by Sven Strickroth which adds a geoip6 module that does both IPv4 and IPv6 country lookups using the popular MaxMind GeoLite databases. I also run dual-stack IPv4 and IPv6 – Awstats includes some useful GeoIP modules to lookup where user traffic comes from, but it doesn’t support mixed IPv4 and IPv6 by default and as my IPv6 traffic usage increases, this could be a problem as the “Unknown” country counter increases. Unfortunately Awstats doesn’t differentiate between general purpose file grabbers and the Yum downloader for RPM-based distributions, and it makes it difficult to see if downloads are from machines vs mirror scripts scanning and re-downloading files. That repository server in particular ( ) is now pushing 20-40GB of traffic per month to around 2500-3000 servers. cat > /etc/sysconfig/httpd << "EOF"įollowing a restart, Apache should now show the correct HOME environmental variable and your application should function as expected. This particular configuration file is read at server startup and isn’t overwritten when Apache gets upgraded. To fix the issue on a RHEL/CentOS host, you can instead just append a replacement HOME setting into /etc/sysconfig/httpd. ![]() LESSOPEN=|/usr/bin/lesspipe.sh %sG_BROKEN_FILENAMES=1_=/usr/sbin/httpdīecause of these settings, external programs relying on the value of HOME will try to read/write to a directory that they aren’t permitted to use.ĭebian-based systems fix this issue by unsetting certain environmentals (including HOME) in the bootscript for Apache, based on the rules in /etc/apache2/envvars. INPUTRC=/etc/inputrcPWD=/rootLANG=CSHLVL=3HOME=/rootLOGNAME=root MAIL=/var/spool/mail/rootPATH=/sbin:/usr/sbin:/bin:/usr/bin HOSTNAME=localhostSHELL=/bin/bashTERM=xtermHISTSIZE=1000USER=root: But after a restart by the root user, it’s clear that some cruft from the root user account has been pulled into the application environment variables: # cat /proc/10175/environ TERM=dumbPATH=/sbin:/usr/sbin:/bin:/usr/binPWD=/LANG=CSHLVL=2_=/usr/sbin/httpdīecause Apache has been started by init, it has a nice clean environment. After a normal boot, the environmental variables look something like the below: In my case, Git kept dying with a fatal error, which lead to a very confused sysadmin wondering why a process running as Apache is trying to read from the root user’s account…īy looking at the environmental settings for the Apache worker processes, we can see what’s happening. ![]() # tail -n1 error.logįatal: unable to access '/root/.config/git/config': Permission denied Generally it won’t be an issue for web applications, but if they call an external application (in my case, Git), that external application may use the HOME environment to try and read or write configuration files. What seems to happen is that when an administrator restarts Apache during general maintenance of that server, Apache picks up some of the unwanted environmental settings from the root user account, in particular the variable HOME ends up getting set to the home directory of the root user account (/root). I’ve run into an issue a couple of times where some web applications on my server have broken following a restart of Apache when the application in question calls external programs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |