Are complete. And they went smoothly.
So now all of those machines are up and running on CentOS 6.3. With their designated IP Addresses.
Are complete. And they went smoothly.
So now all of those machines are up and running on CentOS 6.3. With their designated IP Addresses.
The Moodle configuration check suggests quite a few packages to be installed:
yum -y install php-soap php-intl
Oh, and don’t forget (I did, at first):
apachectl graceful
After installing Moodle, I went to the main URL and it automatically ran some checks, the first of which failed. The message in horrible (or at least, noticeable) red, is this:
It is required that you store all your data in Unicode format (UTF-8). New installations must be performed into databases that have their default character set as Unicode. If you are upgrading, you should perform the UTF-8 migration process (see the Admin page).
Ah, we created the database using our default MySQL useradd script, which creates a database in the default way. Easily fixed:
mysql> show create database moodle_db; +-----------+----------------------------------------------------------------------+ | Database | Create Database | +-----------+----------------------------------------------------------------------+ | moodle_db | CREATE DATABASE `moodle_db` /*!40100 DEFAULT CHARACTER SET latin1 */ | +-----------+----------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> drop database moodle_db; Query OK, 0 rows affected (0.11 sec) mysql> create database moodle_db character set 'utf8'; Query OK, 1 row affected (0.01 sec) mysql> show create database moodle_db; +-----------+--------------------------------------------------------------------+ | Database | Create Database | +-----------+--------------------------------------------------------------------+ | moodle_db | CREATE DATABASE `moodle_db` /*!40100 DEFAULT CHARACTER SET utf8 */ | +-----------+--------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> use moodle_db; Database changed mysql> show variables like "collation"; Empty set (0.01 sec) mysql> show variables like "collation_database"; +--------------------+-----------------+ | Variable_name | Value | +--------------------+-----------------+ | collation_database | utf8_general_ci | +--------------------+-----------------+ 1 row in set (0.00 sec) mysql>
That did the trick!
Hopefully, the general collation will work for Moodle.
Darn it. I just read here: http://docs.moodle.org/24/en/admin/environment/unicode that
Moodle tables are normally set-up using the utf8_unicode_ci collation.
So, I did the following:
mysql> drop database moodle_db; Query OK, 0 rows affected (0.00 sec) mysql> create database moodle_db character set 'utf8' collate 'utf8_unicode_ci'; Query OK, 1 row affected (0.00 sec) mysql> use moodle_db; Database changed mysql> show variables like "collation_database"; +--------------------+-----------------+ | Variable_name | Value | +--------------------+-----------------+ | collation_database | utf8_unicode_ci | +--------------------+-----------------+ 1 row in set (0.00 sec) mysql>
Done!
We followed the instructions for installing Moodle from here: http://docs.moodle.org/24/en/Installing_Moodle with some small variations:
1. We created a “moodle” user and installed the software as that user:
useradd_faculty moodle su - moodle git clone -b MOODLE_24_STABLE git://git.moodle.org/moodle.git mv moodle/* public_html/
Since the files are owned by moodle, they won’t be writable by the web server (apache).
2. We created a MySQL user account:
mysql-useradd.sh moodle random moodle_db
3. We created the moodle data directory in the home directory of the moodle account, not in public_html, following their security guidelines:
mkdir ~/data
4. Now, we need that directory to be writable by apache, so, as root, we did the following:
# chgrp apache ~moodle/data # chmod g+rwx ~moodle/data
5. We then ran their installer:
# chown apache ~moodle/public_html # cd ~moodle/public_html/admin/cli # sudo -u apache /usr/bin/php install.php # chown -R moodle ~moodle/public_html
6. Unfortunately, that asked a lot of questions that we didn’t know the answers to, so we had to do some guessing. We wish their installation instructions had been a bit more comprehensive.
7. And after all that, failure! We get the following in our web browser:
Fatal error: /home/moodle/data is not writable, admin has to fix directory permissions! Exiting
8. We double-checked the data directory, and even opened them up to 777, and no go.
9. Could it be SELinux? Sure could. Do this and here are the new entries that arrive in /var/log/audit/audit.log:
> type=AVC msg=audit(1360875272.798:582224): avc: denied { write } for pid=3259 comm="httpd" name="data" dev=dm-4 ino=36455789 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir > type=SYSCALL msg=audit(1360875272.798:582224): arch=c000003e syscall=21 success=no exit=-13 a0=7f0dfb551e50 a1=2 a2=0 a3=7f0dfb5c6ce0 items=0 ppid=8066 pid=3259 auid=4678 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=21996 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null) [root@tempest ~]
I got that info by the following script, which looks like a generally useful technique to see what SElinux complaints are caused by a particular operation:
[root@tempest moodle] cat /tmp/new-audits #!/bin/bash before=`mktemp audit.before.XXX` after=`mktemp audit.after.XXX` tail -30 /var/log/audit/audit.log > $before GET http://cs.wellesley.edu/~moodle/ tail -30 /var/log/audit/audit.log > $after diff $before $after [root@tempest moodle]
Unfortunately, Moodle’s installation instructions are mute on the subject of SELinux. Still, there’s some promising information here:
http://beginlinux.com/server_training/web-server/976-apache-and-selinux
https://moodle.org/mod/forum/discuss.php?d=114665
http://wiki.centos.org/TipsAndTricks/SelinuxBooleans
I tried the following command, which lists Selinux booleans and a brief description:
[root@tempest moodle] semanage boolean -l | grep httpd httpd_can_network_relay (off , off) Allow httpd to act as a relay httpd_can_network_connect_db (off , off) Allow HTTPD scripts and modules to connect to databases over the network. httpd_use_gpg (off , off) Allow httpd to run gpg in gpg-web domain httpd_enable_cgi (on , on) Allow httpd cgi support httpd_verify_dns (off , off) Allow Apache to query NS records allow_httpd_mod_auth_pam (off , off) Allow Apache to use mod_auth_pam httpd_run_stickshift (off , off) Allow Apache to run in stickshift mode, not transition to passenger httpd_enable_homedirs (on , on) Allow httpd to read home directories allow_httpd_sys_script_anon_write (off , off) Allow apache scripts to write to public content. Directories/Files must be labeled public_rw_content_t. httpd_dbus_avahi (on , on) Allow Apache to communicate with avahi service via dbus httpd_use_cifs (off , off) Allow httpd to access cifs file systems httpd_unified (on , on) Unify HTTPD handling of all content files. httpd_builtin_scripting (on , on) Allow httpd to use built in scripting (usually php) httpd_can_network_connect (off , off) Allow HTTPD scripts and modules to connect to the network using TCP. httpd_tty_comm (on , on) Unify HTTPD to communicate with the terminal. Needed for entering the passphrase for certificates at the terminal. allow_httpd_anon_write (off , off) Allow Apache to modify public files used for public file transfer services. Directories/Files must be labeled public_rw_content_t. httpd_read_user_content (on , on) Allow httpd to read user content httpd_use_nfs (off , off) Allow httpd to access nfs file systems httpd_tmp_exec (off , off) Allow Apache to execute tmp content. httpd_execmem (on , on) Allow httpd scripts and modules execmem/execstack httpd_manage_ipa (off , off) Allow httpd processes to manage IPA content httpd_can_sendmail (on , on) Allow http daemon to send mail httpd_can_check_spam (off , off) Allow http daemon to check spam allow_httpd_mod_auth_ntlm_winbind (off , off) Allow Apache to use mod_auth_ntlm_winbind httpd_can_network_memcache (off , off) Allow httpd to connect to memcache server httpd_can_network_connect_cobbler (off , off) Allow HTTPD scripts and modules to connect to cobbler over the network. httpd_ssi_exec (on , on) Allow HTTPD to run SSI executables in the same domain as system CGI scripts. httpd_use_openstack (off , off) Allow httpd to access openstack ports httpd_enable_ftp_server (off , off) Allow httpd to act as a FTP server by listening on the ftp port. httpd_setrlimit (off , off) Allow httpd daemon to change system limits [root@tempest moodle]
Excellent. Even more focused is this:
[root@tempest moodle] semanage boolean -l | grep httpd | grep write allow_httpd_sys_script_anon_write (off , off) Allow apache scripts to write to public content. Directories/Files must be labeled public_rw_content_t. allow_httpd_anon_write (off , off) Allow Apache to modify public files used for public file transfer services. Directories/Files must be labeled public_rw_content_t. [root@tempest moodle]
Okay, the first of these seems to be worth trying. Let’s give it a go.
First, let’s use the script above to look at selinux alerts:
[root@tempest moodle] sealert -a audit.after.tvn found 1 alerts in audit.after.tvn -------------------------------------------------------------------------------- SELinux is preventing /usr/sbin/httpd from write access on the directory /home/moodle/data ***** Plugin catchall (100. confidence) suggests *************************** If you believe that httpd should be allowed write access on the data directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep httpd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp [root@tempest moodle] grep httpd /var/log/audit/audit.log | audit2allow -M mypol ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i mypol.pp
Okay, so I did the first half of that, grepping for httpd complaints and piping to audit2allow. But I didn’t want to immediately make it active.
[root@tempest moodle] file mypol.* mypol.pp: data mypol.te: ASCII C++ program text, with very long lines [root@tempest moodle] more mypol.te module mypol 1.0; require { type user_tmp_t; type proc_net_t; type user_home_dir_t; type httpd_t; type user_home_t; type sysfs_t; type httpd_suexec_t; type devlog_t; type gconf_home_t; type httpd_sys_script_t; class sock_file write; class lnk_file read; class file { read execute }; class dir { write read getattr search }; } #============= httpd_suexec_t ============== allow httpd_suexec_t user_home_t:file execute; #============= httpd_sys_script_t ============== allow httpd_sys_script_t devlog_t:sock_file write; allow httpd_sys_script_t gconf_home_t:dir search; allow httpd_sys_script_t proc_net_t:file read; allow httpd_sys_script_t sysfs_t:dir search; allow httpd_sys_script_t user_home_dir_t:lnk_file read; allow httpd_sys_script_t user_tmp_t:dir { read getattr }; #============= httpd_t ============== #!!!! The source type 'httpd_t' can write to a 'dir' of the following types: # tmp_t, var_t, tmpfs_t, httpd_log_t, dirsrv_config_t, httpd_tmp_t, dirsrvadmin_tmp_t, httpd_cache_t, httpd_tmpfs_t, var_lib_t, var_run_t, httpd_squirrelmail_t, var_log_t, httpd_mediawiki_tmp_t, dirsrv_var_log_t, zarafa_var_lib_t, dirsrv_var_run_t, httpd_var_lib_t, httpd_var_run_t, dirsrvadmin_config_t, squirrelmail_sp ool_t, var_lock_t, httpd_awstats_ra_content_t, httpd_awstats_rw_content_t, httpd_user_ra_content_t, httpd_user_rw_content_t, httpdcontent, httpd_cobbler_ra_cont ent_t, httpd_cobbler_rw_content_t, httpd_munin_ra_content_t, httpd_munin_rw_content_t, httpd_bugzilla_ra_content_t, httpd_bugzilla_rw_content_t, root_t, httpd_c vs_ra_content_t, httpd_cvs_rw_content_t, httpd_git_ra_content_t, httpd_git_rw_content_t, httpd_sys_ra_content_t, httpd_sys_rw_content_t, httpd_sys_rw_content_t, httpd_nagios_ra_content_t, httpd_nagios_rw_content_t, httpd_nutups_cgi_ra_content_t, httpd_nutups_cgi_rw_content_t, passenger_tmp_t, httpd_apcupsd_cgi_ra_conte nt_t, httpd_apcupsd_cgi_rw_content_t, httpd_mediawiki_ra_content_t, httpd_mediawiki_rw_content_t, httpd_sys_content_t, httpd_squid_ra_content_t, httpd_squid_rw_ content_t, httpd_smokeping_cgi_ra_content_t, httpd_smokeping_cgi_rw_content_t, httpd_prewikka_ra_content_t, httpd_prewikka_rw_content_t, httpd_openshift_ra_cont ent_t, httpd_openshift_rw_content_t, httpd_dirsrvadmin_ra_content_t, httpd_dirsrvadmin_rw_content_t, passenger_var_run_t, httpd_w3c_validator_ra_content_t, http d_w3c_validator_rw_content_t allow httpd_t user_home_t:dir write;
Ick, that’s a lot. Do I really want to do that? Can I be a bit more focussed? Let’s try just changing the selinux context of the data directory to the type suggested in the rule summary, above:
[root@tempest moodle] semanage fcontext -a -t httpd_sys_rw_content data/ libsepol.context_from_record: type httpd_sys_rw_content is not defined (No such file or directory). libsepol.context_from_record: could not create context structure (Invalid argument). libsemanage.validate_handler: invalid context system_u:object_r:httpd_sys_rw_content:s0 specified for data/ [all files] (Invalid argument). libsemanage.dbase_llist_iterate: could not iterate over records (Invalid argument). /usr/sbin/semanage: Could not commit semanage transaction
Darn. So much for following their advice! Let me try a different context:
[root@tempest moodle] semanage fcontext -a -t httpd_sys_rw_content_t data/ [root@tempest moodle] GET http://cs.wellesley.edu/~moodle/ Remote Addr is 149.130.136.40 Fatal error: /home/moodle/data is not writable, admin has to fix directory permissions! Exiting. [root@tempest moodle] ls -ldZ data drwxrwsrwx. apache apache unconfined_u:object_r:user_home_t:s0 data [root@tempest moodle] restorecon -R data [root@tempest moodle] ls -ldZ data drwxrwsrwx. apache apache unconfined_u:object_r:user_home_t:s0 data [root@tempest moodle] !seman semanage fcontext -a -t httpd_sys_rw_content_t data/ [root@tempest moodle] ls -ldZ data drwxrwsrwx. apache apache unconfined_u:object_r:user_home_t:s0 data
Okay, that was a miserable failure. (I later realized that, I think, the problem was that I neededto use an absolute pathname for the files and directories in the semanage command.) Meanwhile, I took another tack. (I’m showing the whole journey because we may have to un-do some of these steps.)
Okay, let’s try that sledgehammer policy file that audit2allow wrote:
[root@tempest moodle] semodule -i mypol.pp [root@tempest moodle] GET http://cs.wellesley.edu/~moodle/ Warning: mkdir(): Permission denied in /home/moodle/public_html/lib/setuplib.php on line 1213 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Error</title> </head><body><div style="margin-top: 6em; margin-left:auto; margin-right:auto; color:#990000; text-align:center; font-size:large; border-width:1px; border-color:black; background-color:#ffffee; border-style:solid; border-radius: 20px; border-collapse: collapse; width: 80%; -moz-border-radius: 20px; padding: 15px"> Unable to save the cache config to file. </div></body></html>[root@tempest moodle]
Okay, so that seems to have pretty much worked. I think.
Later, I realized that I already have a PHP script that is able to write to the filesystem, namely /home/anderson/public_html/cgi-bin/webapps/signup9/database.php. So, I wrote a little script to test writeability for three locations, /tmp, the moodle data directory and my signup9 directory. They are all writable by permissions, so the issue must be SELinux contexts. Here’s what I did:
First, here’s the PHP script:
[root@tempest moodle] cat public_html/testwrite.php <?php function writeable($dir) { if( is_writeable($dir) ) { print "<p>Directory $dir is writeable\n"; } else { print "<p>Directory $dir is <em>not</em> writeable\n"; } $file = "$dir/sda.tmp"; if( !$handle = fopen($file,'wb') ) { print "but couldn't open a file for writing.\n"; return; } if( fwrite($handle,"yes, writeable") === FALSE ) { print "but couldn't write any data to it.\n"; return; } fflush($handle); fclose($handle); } writeable("/tmp"); writeable("/home/moodle/data"); writeable("/home/anderson/public_html/cgi-bin/webapps/signup9"); ?> Let's try it: [root@tempest moodle] GET http://cs.wellesley.edu/~moodle/testwrite.php <p>Directory /tmp is writeable <p>Directory /home/moodle/data is writeable Warning: fopen(/home/moodle/data/sda.tmp): failed to open stream: Permission denied in /home/moodle/public_html/testwrite.php on line 9 but couldn't open a file for writing. <p>Directory /home/anderson/public_html/cgi-bin/webapps/signup9 is writeable Okay so that means the sledgehammer didn't quite work. [root@tempest moodle] ls -ldZ /tmp /home/moodle/data /home/anderson/public_html/cgi-bin/webapps/signup9 drwxrwxrwx. anderson faculty system_u:object_r:httpd_user_content_t:s0 /home/anderson/public_html/cgi-bin/webapps/signup9 drwxrwsr-x. apache apache unconfined_u:object_r:user_home_t:s0 /home/moodle/data drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp [root@tempest moodle] semanage fcontext -a -t httpd_user_content_t /home/moodle/data [root@tempest moodle] ls -ldZ /tmp /home/moodle/data /home/anderson/public_html/cgi-bin/webapps/signup9 drwxrwxrwx. anderson faculty system_u:object_r:httpd_user_content_t:s0 /home/anderson/public_html/cgi-bin/webapps/signup9 drwxrwsr-x. apache apache unconfined_u:object_r:user_home_t:s0 /home/moodle/data drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp [root@tempest moodle] restorecon -v /home/moodle/data restorecon reset /home/moodle/data context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_user_content_t:s0 [root@tempest moodle] ls -ldZ /tmp /home/moodle/data /home/anderson/public_html/cgi-bin/webapps/signup9 drwxrwxrwx. anderson faculty system_u:object_r:httpd_user_content_t:s0 /home/anderson/public_html/cgi-bin/webapps/signup9 drwxrwsr-x. apache apache unconfined_u:object_r:httpd_user_content_t:s0 /home/moodle/data drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp [root@tempest moodle] GET http://cs.wellesley.edu/~moodle/testwrite.php <p>Directory /tmp is writeable <p>Directory /home/moodle/data is writeable <p>Directory /home/anderson/public_html/cgi-bin/webapps/signup9 is writeable [root@tempest moodle]
This is looking good!
Note that I learned that changing a file’s selinux context is a two-step proces from this page: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html
Let’s try the moodle script:
[root@tempest moodle] GET http://cs.wellesley.edu/~moodle/index.php
Warning: mkdir(): Permission denied in /home/moodle/public_html/lib/setuplib.php on line 1213
Warning: mkdir(): Permission denied in /home/moodle/public_html/lib/setuplib.php on line 1188
…
Okay, so there’s more to do. I think this is just an issue of recursively setting the SElinux context:
[root@tempest moodle] find data -exec echo semanage fcontext -a -t httpd_user_content_t /home/moodle/{} \;
semanage fcontext -a -t httpd_user_content_t /home/moodle/data
semanage fcontext -a -t httpd_user_content_t /home/moodle/data/temp
semanage fcontext -a -t httpd_user_content_t /home/moodle/data/cache
semanage fcontext -a -t httpd_user_content_t /home/moodle/data/muc
semanage fcontext -a -t httpd_user_content_t /home/moodle/data/lang
[root@tempest moodle] find data -exec semanage fcontext -a -t httpd_user_content_t /home/moodle/{} \;
[root@tempest moodle] restorecon -R -v /home/moodle/data/
restorecon reset /home/moodle/data/temp context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_user_content_t:s0
restorecon reset /home/moodle/data/cache context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_user_content_t:s0
restorecon reset /home/moodle/data/lang context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_user_content_t:s0
[root@tempest moodle] ls -lRZ data/
data/:
drwxrwsrwx. apache apache unconfined_u:object_r:httpd_user_content_t:s0 cache
drwxrwsrwx. apache apache unconfined_u:object_r:httpd_user_content_t:s0 lang
drwxrwsrwx. apache apache unconfined_u:object_r:httpd_user_content_t:s0 muc
drwxrwsrwx. apache apache unconfined_u:object_r:httpd_user_content_t:s0 temp
data/cache:
data/lang:
data/muc:
data/temp:
[root@tempest moodle] GET http://cs.wellesley.edu/~moodle/index.php
<!DOCTYPE html>
<html dir=”ltr” lang=”en” xml:lang=”en”>
<head>
<title>Installation – Moodle 2.4.1+ (Build: 20130208)</title>
<link rel=”shortcut icon” href=”http://cs.wellesley.edu/~moodle/theme/image.php?theme=standard&component=theme&image=favicon” />
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<meta name=”keywords” content=”moodle, Installation – Moodle 2.4.1+ (Build: 20130208)” />
<meta http-equiv=”pragma” content=”no-cache” />
<meta http-equiv=”expires” content=”0″ />
Yay!
Scott
There’s a small but useful package in Fedora called “pwgen”; it generates random passwords. I’ve used it to generate random passwords for MySQL accounts, for example.
(My reasoning is that those passwords often end up in PHP scripts and such, and so might be viewable by another student. If I allowed students to choose their own passwords, they might reuse a password they are familiar with, one they use for another account. That wouldn’t be secure. Furthermore, if we use a .my.cnf file, there’s no reason anyone should ever have to type a MySQL password, so we might as well make it super-hard to crack.)
However, I’ve had to ssh to Sampras (still running Fedora…) to get these passwords. I couldn’t imagine that pwgen wasn’t available for CentOS/RHEL. Nevertheless:
[root@tempest ~] yum search pwgen Warning: No matches found for: pwgen No Matches found
That can’t be right, I said. Googling for “pwgen centos” found http://pkgs.org/centos-6-rhel-6/epel-i386/pwgen-2.06-5.el6.i686.rpm.html which says it’s available in EPEL. D’oh!
[root@tempest ~] yum repolist all repo id repo name status 10gen 10gen Repository enabled: 6 epel Extra Packages for Enterprise Linux 6 - x86_64 disabled epel-debuginfo Extra Packages for Enterprise Linux 6 - x86_64 - Debug disabled epel-source Extra Packages for Enterprise Linux 6 - x86_64 - Source disabled epel-testing Extra Packages for Enterprise Linux 6 - Testing - x86_64 disabled epel-testing-debuginfo Extra Packages for Enterprise Linux 6 - Testing - x86_64 - Debug disabled epel-testing-source Extra Packages for Enterprise Linux 6 - Testing - x86_64 - Source disabled rhel-source Red Hat Enterprise Linux 6Server - x86_64 - Source disabled rhel-source-beta Red Hat Enterprise Linux 6Server Beta - x86_64 - Source disabled rhel-x86_64-server-6 Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) enabled: 8,896 rhel-x86_64-server-optional-6 RHEL Server Optional (v. 6 64-bit x86_64) enabled: 5,475 rpmforge RHEL 6Server - RPMforge.net - dag disabled rpmforge-extras RHEL 6Server - RPMforge.net - extras disabled rpmforge-testing RHEL 6Server - RPMforge.net - testing disabled repolist: 14,377 [root@tempest ~] yum --enablerepo=epel search pwgen ============================================= N/S Matched: pwgen ============================================== pwgen.x86_64 : Automatic password generation Name and summary matches only, use "search all" for everything. [root@tempest ~] yum --enablerepo=epel -y install pwgen .... Installed: pwgen.x86_64 0:2.06-5.el6 Complete! [root@tempest ~]
Querying the RPM database is harder than I’d expect. I was having trouble with cups, and so I thought I’d verify the package, in case some file was missing or had the wrong permissions:
[root@tempest ~] rpm -V cups .M....... c /etc/cups/subscriptions.conf [root@tempest ~]
Okay, so the permissions on that file might be wrong. What are they supposed to be? Not so easy to find out. I finally found the following:
[root@tempest ~] rpm -qvl cups | grep /etc/cups/sub -rw-r--r-- 1 root lp 0 Nov 6 06:42 /etc/cups/subscriptions.conf [root@tempest ~]
and what is that file currently?
[root@tempest cups] ls -l /etc/cups/subscriptions.conf -rw-r-----. 1 root lp 564 Feb 1 13:36 /etc/cups/subscriptions.conf
Okay, so if I change that, the package will complete verify, right?
[root@tempest cups] ls -l /etc/cups/subscriptions.conf -rw-r-----. 1 root lp 564 Feb 1 13:36 /etc/cups/subscriptions.conf [root@tempest cups] chmod 644 !$ chmod 644 /etc/cups/subscriptions.conf [root@tempest cups] rpm -V cups [root@tempest cups]
Okay! Not that that fixed my problem….
In installing selenium and pymongo on the clients, I discovered some errors in some of the scripts in /usr/network/scripts/parts that install python packages:
So I fixed the following scripts, which use pip and/or opendir: orange.sh, selenium.sh, stemming.sh, and gensim.sh. Then I broadcast selenium.sh, and stemming.sh. I didn’t broadcast orange.sh or gensim.sh, since I don’t know if we need them, and there are some details I don’t understand. That will have to wait until someone actually need these packages, and can test them.
BTW, the client list that our various broadcast scripts use, /etc/clients-centos, is missing 8 machines due to ssh key issues. See the comments in that file. We should fix that so these machines don’t get out of sync with the others.
Eni and I are resuscitating the NY Times scraping project and we want to get some new data. So I’m using the good ol’ trustus account that Olivia, Emily and I used in Tyler’s course last spring.
I’ve encountered this annoyance before:
~$ ssh -Y trustus@cs trustus@cs's password: Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Wed Jan 30 12:05:09 2013 from 149.130.206.39 /usr/bin/xauth: timeout in locking authority file /students/trustus/.Xauthority
The timeout is about 20 seconds. Of course the culprit is SELinux, as we see in the user-friendly error messages in /var/log/audit/audit.log:
type=AVC msg=audit(1359565919.330:411758): avc: denied { write } for pid=4001 comm="xauth" name="trustus" dev=dm-2 ino=1209019 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
Let’s compare some home directories:
[root@tempest log] ls -lZd /home/anderson/ drwxr-x--x. anderson anderson unconfined_u:object_r:user_home_dir_t:s0 /home/anderson/ [root@tempest log] ls -lZd /students/edavis5/ drwxr-x--x. edavis5 edavis5 system_u:object_r:user_home_dir_t:s0 /students/edavis5/ [root@tempest log] ls -lZd /students/trustus/ drwxr-x--x. trustus trustus system_u:object_r:home_root_t:s0 /students/trustus/ [root@tempest log]
Clearly that home_root_t is the problem. Only /home and /students are supposed to have that; their contents should be user_home_t. Let’s look more carefully at all the home directories:
[root@tempest log] ls -lZ /home|sort -k4 drwxr-x--x. cs110s12 cs110s12 system_u:object_r:home_root_t:s0 appinv-stats drwxrwx--x. mjust mjust system_u:object_r:home_root_t:s0 mjust drwx------. root root system_u:object_r:lost_found_t:s0 lost+found drwxr-x--x. anderson anderson unconfined_u:object_r:user_home_dir_t:s0 anderson drwxrwxr-x. 91 tomcat unconfined_u:object_r:user_home_dir_t:s0 apache-tomcat-5.5.26 . . # Remainder all same: unconfined_u:object_r:user_home_dir_t:s0 [root@tempest log] ls -lZ /students |sort -k4 drwxr-x--x. cdefries cdefries system_u:object_r:home_root_t:s0 cdefries drwxr-x--x. emilyuki emilyuki system_u:object_r:home_root_t:s0 emilyuki drwxr-x--x. forsale forsale system_u:object_r:home_root_t:s0 forsale drwxr-x--x. mkorpusi mkorpusi system_u:object_r:home_root_t:s0 mkorpusi drwxr-x--x. raw raw system_u:object_r:home_root_t:s0 raw drwxr-x--x. skyteam skyteam system_u:object_r:home_root_t:s0 skyteam drwxr-x--x. theclean theclean system_u:object_r:home_root_t:s0 theclean drwxr-x--x. thejolly thejolly system_u:object_r:home_root_t:s0 thejolly drwxr-x--x. trustus trustus system_u:object_r:home_root_t:s0 trustus drwx------. root root system_u:object_r:lost_found_t:s0 lost+found dr-x--x--x. 2sustain 2sustain system_u:object_r:user_home_dir_t:s0 2sustain dr-xr-x--x. 8ninjas8 8ninjas8 system_u:object_r:user_home_dir_t:s0 8ninjas8 drwxr-x--x. aaaron aaaron system_u:object_r:user_home_dir_t:s0 aaaron drwxr-x--x. aadidako aadidako system_u:object_r:user_home_dir_t:s0 aadidako drwxr-x--x. aahiable aahiable system_u:object_r:user_home_dir_t:s0 aahiable . . # 1000 like this . drwxr-x--x. zsutton zsutton system_u:object_r:user_home_dir_t:s0 zsutton drwxr-x--x. zyue zyue system_u:object_r:user_home_dir_t:s0 zyue -rw-------. root root unconfined_u:object_r:quota_db_t:s0 aquota.group -rw-------. root root unconfined_u:object_r:quota_db_t:s0 aquota.user drwxr-x--x. aali3 aali3 unconfined_u:object_r:user_home_dir_t:s0 aali3 drwxr-x--x. aarora aarora unconfined_u:object_r:user_home_dir_t:s0 aarora drwxr-x--x. ablige ablige unconfined_u:object_r:user_home_dir_t:s0 ablige drwxr-x--x. absz2012 absz2012 unconfined_u:object_r:user_home_dir_t:s0 absz2012 . . # 300 like this .
The four fields are user, role, type, and security level. I’d love to understand this stuff, but no time. The restorecon command fixes only the type unless you use the -F option, so perhaps that’s the important one.
Focusing on the type, then, I nervously pulled the trigger on ‘restorecon -pR /students/trustus/’. That changed the type of all the files to match the other student directories:
[root@tempest students] ls -lZd trustus/ drwxr-x--x. trustus trustus system_u:object_r:user_home_dir_t:s0 trustus/ [root@tempest students] ls -lZ trustus/ -rw-rw----. trustus trustus system_u:object_r:user_home_t:s0 59508062.json drwxrwxr-x. trustus trustus system_u:object_r:user_home_t:s0 ai_ek drwxrwx---. trustus trustus system_u:object_r:user_home_t:s0 code . .
And now I can ssh in without delay, so, problem solved.
I think that the above difference in user type comes from when the account was created. In /students, old-timers like choover, cgrote, and dgerr are all system_u; conversely students added recently all appear to be unconfined_u. Probably the dividing line is when we copied everything from puma to tempest. According to Sec. 3.3 of the RHEL SELinux User Guide , unconfined_u is the default. I assume the system_u’s came from the copying process from puma, and the ‘restorecon -R -v /students’ that Scott did on 2/21/2012 did not change them to the default because the -F flag was not specified. I’d bet that it’s not important, but I’m not certain.
Now we should probably restorecon these accounts in /students (probably most are no longer used): cdefries, emilyuki, forsale, mkorpusi, raw, skyteam. theclean, thejolly. Ditto for appinv-stats and mjust in /home, although they’re not used either. I’ll do that in a couple days after I use trustus a bit and am sure everything’s OK.
Update Feb. 22, 2013
Everything was fine with trustus after I made the above change, so I also restorecon-ed all the accounts mentioned in the previous paragraph. Now all the “type” fields in /home and /students are as they should be; the only discrepancies are for system files such as lost+found and aquota.*, as you’d expect.
The first field, “user”, is still non-uniform. Accounts copied from puma are system_u (I read somewhere that this is inherited from the copying process). New accounts are unconfined_u. I think this is fixable using “restorecon -F”. However, according to the RHEL 6 SELinux User Guide, “Type Enforcement is the main permission control used in SELinux targeted policy. For the most part, SELinux users and roles can be ignored.” I don’t want to risk a disaster messing with something I don’t understand, so I’m going to leave it alone.
The packages in EPEL (see http://fedoraproject.org/wiki/EPEL) depend on the optional subchannel. The directions are https://access.redhat.com/knowledge/solutions/11312, and so I enabled the sub-channel for Tempest.
I can confirm this by doing:
[root@tempest ~] yum repolist Loaded plugins: downloadonly, product-id, refresh-packagekit, rhnplugin, security, subscription-manager Updating certificate-based repositories. Unable to read consumer identity rhel-x86_64-server-optional-6 | 1.8 kB 00:00 rhel-x86_64-server-optional-6/primary | 1.3 MB 00:00 rhel-x86_64-server-optional-6 5455/5455 repo id repo name status 10gen 10gen Repository 6 rhel-x86_64-server-6 Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) 8,830 rhel-x86_64-server-optional-6 RHEL Server Optional (v. 6 64-bit x86_64) 5,455 repolist: 14,291 [root@tempest ~]
Maybe this will let us install stuff like Ocaml?
[root@tempest ~] yum search ocaml Loaded plugins: downloadonly, product-id, refresh-packagekit, rhnplugin, security, subscription-manager Updating certificate-based repositories. Unable to read consumer identity ===================================================== N/S Matched: ocaml ===================================================== ocaml-calendar-devel.i686 : Development files for ocaml-calendar ocaml-calendar-devel.x86_64 : Development files for ocaml-calendar ocaml-csv.x86_64 : OCaml library for reading and writing CSV files ocaml-csv-devel.i686 : Development files for ocaml-csv ocaml-csv-devel.x86_64 : Development files for ocaml-csv ocaml-curses.x86_64 : OCaml bindings for ncurses ocaml-curses-devel.i686 : Development files for ocaml-curses ocaml-curses-devel.x86_64 : Development files for ocaml-curses ocaml-extlib.x86_64 : OCaml ExtLib additions to the standard library ocaml-extlib-devel.i686 : Development files for ocaml-extlib ocaml-extlib-devel.x86_64 : Development files for ocaml-extlib ocaml-fileutils.x86_64 : OCaml library for common file and filename operations ocaml-fileutils-devel.i686 : Development files for ocaml-fileutils ocaml-fileutils-devel.x86_64 : Development files for ocaml-fileutils ocaml-findlib-devel.i686 : Development files for ocaml-findlib ocaml-findlib-devel.x86_64 : Development files for ocaml-findlib ocaml-gettext.x86_64 : OCaml library for i18n ocaml-gettext-devel.i686 : Development files for ocaml-gettext ocaml-gettext-devel.x86_64 : Development files for ocaml-gettext ocaml-hivex.x86_64 : OCaml bindings for hivex ocaml-hivex-devel.i686 : OCaml bindings for hivex ocaml-hivex-devel.x86_64 : OCaml bindings for hivex ocaml-libguestfs.x86_64 : OCaml bindings for libguestfs ocaml-libguestfs-devel.x86_64 : OCaml bindings for libguestfs ocaml-libvirt.x86_64 : OCaml binding for libvirt ocaml-libvirt-devel.i686 : Development files for ocaml-libvirt ocaml-libvirt-devel.x86_64 : Development files for ocaml-libvirt ocaml-xml-light.x86_64 : Minimal XML parser and printer for OCaml ocaml-xml-light-devel.i686 : Development files for ocaml-xml-light ocaml-xml-light-devel.x86_64 : Development files for ocaml-xml-light ocaml.x86_64 : Objective Caml compiler and programming environment ocaml-calendar.x86_64 : Objective Caml library for managing dates and times ocaml-camlp4.x86_64 : Pre-Processor-Pretty-Printer for Objective Caml ocaml-camlp4-devel.i686 : Pre-Processor-Pretty-Printer for Objective Caml ocaml-camlp4-devel.x86_64 : Pre-Processor-Pretty-Printer for Objective Caml ocaml-docs.x86_64 : Documentation for Objective Caml ocaml-emacs.x86_64 : Emacs mode for Objective Caml ocaml-findlib.x86_64 : Objective CAML package manager and build helper ocaml-labltk.x86_64 : Tk bindings for Objective Caml ocaml-labltk-devel.i686 : Development files for labltk ocaml-labltk-devel.x86_64 : Development files for labltk ocaml-ocamldoc.x86_64 : Documentation generator for Objective Caml. ocaml-runtime.x86_64 : Objective Caml runtime environment ocaml-source.x86_64 : Source code for Objective Caml libraries ocaml-x11.x86_64 : X11 support for Objective Caml Name and summary matches only, use "search all" for everything. [root@tempest ~]
Yay! Let’s do it:
[root@tempest ~] cat /usr/network/scripts/parts/ocaml.sh #!/bin/bash yum install -y ocaml ocaml-docs ocaml-emacs ocaml-findlib ocaml-runtime ocaml-source ocaml-x11 ocaml-fileutils ocaml-gettext [root@tempest ~] /usr/network/scripts/parts/ocaml.sh Dependencies Resolved ============================================================================================================================== Package Arch Version Repository Size ============================================================================================================================== Installing: ocaml x86_64 3.11.2-2.el6 rhel-x86_64-server-optional-6 5.2 M ocaml-docs x86_64 3.11.2-2.el6 rhel-x86_64-server-optional-6 2.0 M ocaml-emacs x86_64 3.11.2-2.el6 rhel-x86_64-server-optional-6 84 k ocaml-fileutils x86_64 0.4.0-4.1.el6 rhel-x86_64-server-optional-6 31 k ocaml-findlib x86_64 1.2.5-5.el6 rhel-x86_64-server-optional-6 311 k ocaml-gettext x86_64 0.3.3-3.5.el6 rhel-x86_64-server-optional-6 61 k ocaml-runtime x86_64 3.11.2-2.el6 rhel-x86_64-server-optional-6 1.3 M ocaml-source x86_64 3.11.2-2.el6 rhel-x86_64-server-optional-6 82 k ocaml-x11 x86_64 3.11.2-2.el6 rhel-x86_64-server-optional-6 12 k Installing for dependencies: gdbm-devel x86_64 1.8.0-36.el6 rhel-x86_64-server-optional-6 25 k ocaml-camlp4 x86_64 3.11.2-2.el6 rhel-x86_64-server-optional-6 11 M Transaction Summary ============================================================================================================================== Install 11 Package(s) Complete! [root@tempest ~]
Some other useful commands to know. Here’s how to find out all the repos, including disabled ones:
[root@tempest ~] yum repolist all Loaded plugins: downloadonly, product-id, refresh-packagekit, rhnplugin, security, subscription-manager Updating certificate-based repositories. Unable to read consumer identity repo id repo name status 10gen 10gen Repository enabled: 6 epel Extra Packages for Enterprise Linux 6 - x86_64 disabled epel-debuginfo Extra Packages for Enterprise Linux 6 - x86_64 - Debug disabled epel-source Extra Packages for Enterprise Linux 6 - x86_64 - Source disabled epel-testing Extra Packages for Enterprise Linux 6 - Testing - x86_64 disabled epel-testing-debuginfo Extra Packages for Enterprise Linux 6 - Testing - x86_64 - Debug disabled epel-testing-source Extra Packages for Enterprise Linux 6 - Testing - x86_64 - Source disabled rhel-source Red Hat Enterprise Linux 6Server - x86_64 - Source disabled rhel-source-beta Red Hat Enterprise Linux 6Server Beta - x86_64 - Source disabled rhel-x86_64-server-6 Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) enabled: 8,830 rhel-x86_64-server-optional-6 RHEL Server Optional (v. 6 64-bit x86_64) enabled: 5,455 rpmforge RHEL 6Server - RPMforge.net - dag disabled rpmforge-extras RHEL 6Server - RPMforge.net - extras disabled rpmforge-testing RHEL 6Server - RPMforge.net - testing disabled repolist: 14,291 [root@tempest ~]
I think it’s possible to enable optional repos via yum-config-manager, but I haven’t tried this. See https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/entitlements-and-yum.html#supplementary-repos
Finally, I wanted to add EPEL. I found http://fedoraproject.org/wiki/EPEL which has a link to the “newest version of epel-release for EL6” (linking to some random mirror site).
Down the file (epel-release-6-8.noarch.rpm) and install:
[root@tempest apps] wget mirror.cc.columbia.edu/pub/linux/epel/6/i386/epel-release-6-8.noarch.rpm Saving to: “epel-release-6-8.noarch.rpm” [root@tempest apps] file epel-release-6-8.noarch.rpm epel-release-6-8.noarch.rpm: RPM v3.0 bin noarch epel-release-6-8 [root@tempest apps] rpm -ivh epel-release-6-8.noarch.rpm Preparing... ########################################### [100%] 1:epel-release ########################################### [100%] [root@tempest apps] yum repolist all repo id repo name status 10gen 10gen Repository enabled: 6 epel Extra Packages for Enterprise Linux 6 - x86_64 disabled epel-debuginfo Extra Packages for Enterprise Linux 6 - x86_64 - Debug disabled epel-source Extra Packages for Enterprise Linux 6 - x86_64 - Source disabled epel-testing Extra Packages for Enterprise Linux 6 - Testing - x86_64 disabled epel-testing-debuginfo Extra Packages for Enterprise Linux 6 - Testing - x86_64 - Debug disabled epel-testing-source Extra Packages for Enterprise Linux 6 - Testing - x86_64 - Source disabled rhel-source Red Hat Enterprise Linux 6Server - x86_64 - Source disabled rhel-source-beta Red Hat Enterprise Linux 6Server Beta - x86_64 - Source disabled rhel-x86_64-server-6 Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) enabled: 8,830 rhel-x86_64-server-optional-6 RHEL Server Optional (v. 6 64-bit x86_64) enabled: 5,455 rpmforge RHEL 6Server - RPMforge.net - dag disabled rpmforge-extras RHEL 6Server - RPMforge.net - extras disabled rpmforge-testing RHEL 6Server - RPMforge.net - testing disabled repolist: 14,291 [root@tempest apps] yum --enablerepo=epel search xpdf xpdf.x86_64 : A PDF file viewer for the X Window System [root@tempest apps] yum -y --enablerepo=epel install xpdf Installing: xpdf x86_64 1:3.02-16.el6 epel 802 k Installed: xpdf.x86_64 1:3.02-16.el6 Dependency Installed: t1lib.x86_64 0:5.1.2-6.el6_2.1 xorg-x11-fonts-ISO8859-1-75dpi.noarch 0:7.2-9.1.el6 Complete! [root@tempest apps]
Woo-hoo!
I poked around https://rhn.redhat.com/rhn/systems/SystemEntitlements.do for way too long, and couldn’t figure out how to purchase a renewal of our RHEL server support.
I finally found https://www.redhat.com/wapps/store/catalog.html and clicked on the “buy online” link at the top.
I went to the section headed Red Hat Enterprise Linux Server for 32/64-bit x86 and clicked on the button for Standard Subscription (1 year).
The rest was straightforward e-purchase stuff.