Re: [Discuss] selinux nightmare
On 09/28/2014 06:55 PM, Chuck Anderson wrote: On Sun, Sep 28, 2014 at 04:25:06PM -0400, Stephen Adler wrote: P.S. this is the kind of stuff I'm confronting [root@mipdata0 ~]# sealert -l dd884c85-199f-49c5-b44c-a595ce3cec43 SELinux is preventing /usr/bin/python2.7 from read access on the lnk_file . First, I recommend reading Dan Walsh's blog. Every time someone asks a question on a mailing list, he writes a blog entry with the answer: http://danwalsh.livejournal.com/ A couple general points: - Use a distro that ships with SELinux enabled by default. Chances are most standard things will work out of the box. - If you were using Permissive mode or disabled SELinux completely on an install, it is imperative that you do an SELinux relabel after re-enabling SELinux. In some cases, you may need to enable SELinux in Permissive mode in order to boot far enough to run the relabel. In Fedora/Red Hat, you can trigger a relabel by doing: touch /.autorelabel and rebooting. - You will have the fewest problems if you stick to the standard directory locations for various files. E.g. /var/www for web stuff. That isn't to say you can put things other places, but if you do you may need to adjust policy with e.g. semanage fcontext. To see all the directory locations and what SELinux labels are applied to them, look here: /etc/selinux/targeted/contexts/files - If you move files rather than copying them from e.g. /home to /var/www, you will need to relabel them, e.g.: restorecon -R /var/www/html/foo This is because moved files keep their same file context, whereas copied files or newly created files inherit their file context from the parent directory they are created in. - If you are using non-packaged (self-compiled or third-party downloaded) software or software that isn't distributed as part of the distribution's normal install/update repositories, you may have more problems depending on whether that software is using standard FHS directory locations, etc. Again, you can adjust policy to handle these cases, but the path of least resistance is to avoid it. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss Thanks, this is very helpful. Cheers. Steve. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] selinux nightmare
Chuck is spot on. Dan is the center of wisdom, and other advise looked good. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] selinux nightmare
On Sun, Sep 28, 2014 at 04:25:06PM -0400, Stephen Adler wrote: > P.S. this is the kind of stuff I'm confronting > > [root@mipdata0 ~]# sealert -l dd884c85-199f-49c5-b44c-a595ce3cec43 > SELinux is preventing /usr/bin/python2.7 from read access on the lnk_file . First, I recommend reading Dan Walsh's blog. Every time someone asks a question on a mailing list, he writes a blog entry with the answer: http://danwalsh.livejournal.com/ A couple general points: - Use a distro that ships with SELinux enabled by default. Chances are most standard things will work out of the box. - If you were using Permissive mode or disabled SELinux completely on an install, it is imperative that you do an SELinux relabel after re-enabling SELinux. In some cases, you may need to enable SELinux in Permissive mode in order to boot far enough to run the relabel. In Fedora/Red Hat, you can trigger a relabel by doing: touch /.autorelabel and rebooting. - You will have the fewest problems if you stick to the standard directory locations for various files. E.g. /var/www for web stuff. That isn't to say you can put things other places, but if you do you may need to adjust policy with e.g. semanage fcontext. To see all the directory locations and what SELinux labels are applied to them, look here: /etc/selinux/targeted/contexts/files - If you move files rather than copying them from e.g. /home to /var/www, you will need to relabel them, e.g.: restorecon -R /var/www/html/foo This is because moved files keep their same file context, whereas copied files or newly created files inherit their file context from the parent directory they are created in. - If you are using non-packaged (self-compiled or third-party downloaded) software or software that isn't distributed as part of the distribution's normal install/update repositories, you may have more problems depending on whether that software is using standard FHS directory locations, etc. Again, you can adjust policy to handle these cases, but the path of least resistance is to avoid it. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
[Discuss] selinux nightmare
Hi all, So I'm brining up apache on my new server and I'm trying to do right by selinux this time. My default mode is to ignore selinux, put it in permissive mode, and watch all the error messages get logged but pretty much ignore what's going on under the selinux hood. Well, I figure this time I should pay some attention and at least try and minimize all the error messages I get in my log files. But now I'm in an selinux rabbit hole. The selinux security apparatus is just too complicated to try and figure out without doing some rtfming So... can anyone suggest a good selinux for dummies web site I can pour through? It would love for it to be no more than one single page with a few key commands that I can learn and be done with it. But I doubt that's the case. I think I've gone long enough trying to avoid learning selinux. I've reached the point that I need to really understand it... Thanks. Steve. P.S. this is the kind of stuff I'm confronting [root@mipdata0 ~]# sealert -l dd884c85-199f-49c5-b44c-a595ce3cec43 SELinux is preventing /usr/bin/python2.7 from read access on the lnk_file . * Plugin catchall_labels (83.8 confidence) suggests *** If you want to allow python2.7 to have read access on the lnk_file Then you need to change the label on $FIX_TARGET_PATH Do # semanage fcontext -a -t FILE_TYPE '$FIX_TARGET_PATH' where FILE_TYPE is one of the following: abrt_retrace_spool_t, admin_home_t, bin_t, boot_t, calamaris_www_t, cert_t, cobbler_var_lib_t, cvs_data_t, device_t, devlog_t, dirsrv_share_t, etc_runtime_t, etc_t, file_context_t, fonts_cache_t, fonts_t, git_sys_content_t, gitosis_var_lib_t, home_root_t, httpd_apcupsd_cgi_content_t, httpd_apcupsd_cgi_htaccess_t, httpd_apcupsd_cgi_ra_content_t, httpd_apcupsd_cgi_rw_content_t, httpd_apcupsd_cgi_script_exec_t, httpd_awstats_content_t, httpd_awstats_htaccess_t, httpd_awstats_ra_content_t, httpd_awstats_rw_content_t, httpd_awstats_script_exec_t, httpd_bugzilla_content_t, httpd_bugzilla_htaccess_t, httpd_bugzilla_ra_content_t, httpd_bugzilla_rw_content_t, httpd_bugzilla_script_exec_t, httpd_cache_t, httpd_collectd_content_t, httpd_collectd_htaccess_t, httpd_collectd_ra_content_t, httpd_collectd_rw_content_t, httpd_collectd_script_exec_t, httpd_config_t, httpd_cvs_content_t, httpd_cvs_htaccess_t, httpd_cvs_ra_content_t, httpd_cvs_rw_content_t, httpd_cvs_script_exec_t, httpd_dirsrvadmin_content_t, httpd_dirsrvadmin_htaccess_t, httpd_dirsrvadmin_ra_content_t, httpd_dirsrvadmin_rw_content_t, httpd_dirsrvadmin_script_exec_t, httpd_dspam_content_t, httpd_dspam_htaccess_t, httpd_dspam_ra_content_t, httpd_dspam_rw_content_t, httpd_dspam_script_exec_t, httpd_git_content_t, httpd_git_htaccess_t, httpd_git_ra_content_t, httpd_git_rw_content_t, httpd_git_script_exec_t, httpd_log_t, httpd_man2html_content_t, httpd_man2html_htaccess_t, httpd_man2html_ra_content_t, httpd_man2html_rw_content_t, httpd_man2html_script_exec_t, httpd_mediawiki_content_t, httpd_mediawiki_htaccess_t, httpd_mediawiki_ra_content_t, httpd_mediawiki_rw_content_t, httpd_mediawiki_script_exec_t, httpd_modules_t, httpd_mojomojo_content_t, httpd_mojomojo_htaccess_t, httpd_mojomojo_ra_content_t, httpd_mojomojo_rw_content_t, httpd_mojomojo_script_exec_t, httpd_munin_content_t, httpd_munin_htaccess_t, httpd_munin_ra_content_t, httpd_munin_rw_content_t, httpd_munin_script_exec_t, httpd_mythtv_content_t, httpd_mythtv_htaccess_t, httpd_mythtv_ra_content_t, httpd_mythtv_rw_content_t, httpd_mythtv_script_exec_t, httpd_nagios_content_t, httpd_nagios_htaccess_t, httpd_nagios_ra_content_t, httpd_nagios_rw_content_t, httpd_nagios_script_exec_t, httpd_nutups_cgi_content_t, httpd_nutups_cgi_htaccess_t, httpd_nutups_cgi_ra_content_t, httpd_nutups_cgi_rw_content_t, httpd_nutups_cgi_script_exec_t, httpd_openshift_content_t, httpd_openshift_htaccess_t, httpd_openshift_ra_content_t, httpd_openshift_rw_content_t, httpd_openshift_script_exec_t, httpd_prewikka_content_t, httpd_prewikka_htaccess_t, httpd_prewikka_ra_content_t, httpd_prewikka_rw_content_t, httpd_prewikka_script_exec_t, httpd_smokeping_cgi_content_t, httpd_smokeping_cgi_htaccess_t, httpd_smokeping_cgi_ra_content_t, httpd_smokeping_cgi_rw_content_t, httpd_smokeping_cgi_script_exec_t, httpd_squid_content_t, httpd_squid_htaccess_t, httpd_squid_ra_content_t, httpd_squid_rw_content_t, httpd_squid_script_exec_t, httpd_squirrelmail_t, httpd_sys_content_t, httpd_sys_htaccess_t, httpd_sys_ra_content_t, httpd_sys_rw_content_t, httpd_sys_script_exec_t, httpd_tmp_t, httpd_tmpfs_t, httpd_user_content_t, httpd_user_htaccess_t, httpd_user_ra_content_t, httpd_user_rw_content_t, httpd_user_script_exec_t, httpd_w3c_validator_content_t, httpd_w3c_validator_htaccess_t, httpd_w3c_validator_ra_content_t, httpd_w3c_validator_rw_content_t, httpd_w3c_validator_script_exec_t, httpd_webalizer_content_t, httpd_webalizer_htaccess_t, httpd_webalizer_ra_content_t, httpd_webalizer_rw_co
Re: [Discuss] Monitoring your AWS instances
We use Nagios and nrpe with a pretty standard monitoring setup. We also pull in cloudwatch data via python goto scripts. As for the uptick I would avoid making any changes until after the AWS maintenance. We have also noticed an uptick in alerts,though not to that level. However just because your systems are not directly effected the increased activity due to others replacing systems, as well as what ever amazon is actually doing on the back end, means everyone will be effected to some extent. On Sep 28, 2014 11:06 AM, "Edward Ned Harvey (blu)" wrote: > > From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- > > bounces+blu=nedharvey@blu.org] On Behalf Of Chuck Anderson > > > > Maybe this? > > https://aws.amazon.com/blogs/aws/ec2-maintenance-update/ > > I am aware of that - but they say less than 10% of their systems will be > affected, and "Customers who aren't sure if they are impacted should go to > the "Events" page on the EC2 console, which will list any pending instance > reboots for their AWS account." > > None of our systems are supposed to be impacted, and indeed, none of them > have been rebooting. > > The best I can tell, we're supposed to be unaffected, but the fragile > network is buckling and straining under the load, and causing rolling > network outages. > > I mentioned before, that during the last several months (May or so) we've > seen enormous variability in Amazon network performance... Sometimes you > download or upload a file and it goes 30Mbit/sec, sometimes 15KB/sec. And > it varies from minute to minute, hour to hour, day to day. > ___ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Monitoring your AWS instances
Did you get an email telling you about reboots begin scheduled? I know I have a number of systems being rebooted today around 2pm. If you log into the console, and go to EC2 then click on Events on the left side it will show you any ones that are scheduled in the future. If you change one of the drop down options it will show you closed events. Matt On Sun, Sep 28, 2014 at 9:56 AM, Edward Ned Harvey (blu) wrote: > I would really like to hear from anybody else who has AWS machines, and > alerting/monitoring of those systems (by a system other than Amazon's own > monitoring system). > > The number of alerts I'm receiving about systems being unreachable and > then becoming reachable again is ... Crazy to say the least. Several dozen > last night alone, several dozen in the prior week, several dozen again each > weekend for the last several weeks. It's horrible. > > All systems being monitored, as well as the system doing the monitoring, > are in US VA East. > ___ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Monitoring your AWS instances
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- > bounces+blu=nedharvey@blu.org] On Behalf Of Chuck Anderson > > Maybe this? > https://aws.amazon.com/blogs/aws/ec2-maintenance-update/ I am aware of that - but they say less than 10% of their systems will be affected, and "Customers who aren't sure if they are impacted should go to the "Events" page on the EC2 console, which will list any pending instance reboots for their AWS account." None of our systems are supposed to be impacted, and indeed, none of them have been rebooting. The best I can tell, we're supposed to be unaffected, but the fragile network is buckling and straining under the load, and causing rolling network outages. I mentioned before, that during the last several months (May or so) we've seen enormous variability in Amazon network performance... Sometimes you download or upload a file and it goes 30Mbit/sec, sometimes 15KB/sec. And it varies from minute to minute, hour to hour, day to day. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Monitoring your AWS instances
None of our systems are scheduled for reboot, *and* the machines triggering our alerts have not been rebooting - they just become unavailable on the network for a few minutes and then reappear, without any sort of crash or reboot or anything affecting "uptime." *And* this has been a general issue progressively getting worse and worse over the last several months (but especially bad lately.) For the sake of discussion here, I just pulled reports on the numbers of alerts isolated to Amazon: 2013 Aug: 4 2013 Sep: 0 2013 Oct: 1 2013 Nov: 0 2013 Dec: 0 2014 Jan: 6 2014 Feb: 0 2014 Mar: 0 2014 Apr: 0 2014 May: 0 2014 Jun: 0 2014 Jul: 6 2014 Aug: 8 2014 Sep: from 9/1 to 9/12: 8 2014 Sep: weekend of 9/13 & 9/14: 58 2014 Sep: from 9/15 to 9/19:18 2014 Sep: weekend of 9/20 & 9/21: 8 2014 Sep: from 9/22 to 9/26:24 2014 Sep: weekend of 9/27 & 9/28: 70 (so far) 2014 Sep: 186 (so far) ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Monitoring your AWS instances
On Sun, Sep 28, 2014 at 01:56:07PM +, Edward Ned Harvey (blu) wrote: > I would really like to hear from anybody else who has AWS machines, and > alerting/monitoring of those systems (by a system other than Amazon's own > monitoring system). > > The number of alerts I'm receiving about systems being unreachable and then > becoming reachable again is ... Crazy to say the least. Several dozen last > night alone, several dozen in the prior week, several dozen again each > weekend for the last several weeks. It's horrible. > > All systems being monitored, as well as the system doing the monitoring, are > in US VA East. Maybe this? https://aws.amazon.com/blogs/aws/ec2-maintenance-update/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
[Discuss] Monitoring your AWS instances
I would really like to hear from anybody else who has AWS machines, and alerting/monitoring of those systems (by a system other than Amazon's own monitoring system). The number of alerts I'm receiving about systems being unreachable and then becoming reachable again is ... Crazy to say the least. Several dozen last night alone, several dozen in the prior week, several dozen again each weekend for the last several weeks. It's horrible. All systems being monitored, as well as the system doing the monitoring, are in US VA East. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
