I set this up on a CentOS 5.2 virtual machine. You should have the following packages installed:
sendmail
sendmail-cf
cyrus-sasl
cyrus-sasl-lib
cyrus-sasl-plain
openssl

First let’s generate our self signed certificate. Be sure and use the FQDN of your server for the machine name.

cd /etc/pki/tls/certs
make sendmail.pem
umask 77 ; \
PEM1=`/bin/mktemp /tmp/openssl.XXXXXX` ; \
PEM2=`/bin/mktemp /tmp/openssl.XXXXXX` ; \
/usr/bin/openssl req -utf8 -newkey rsa:1024 -keyout $PEM1 -nodes -x509 -days 365 -out $PEM2 -set_serial 0 ; \
cat $PEM1 > test.pem ; \
echo "" >> test.pem ; \
cat $PEM2 >> test.pem ; \
rm -f $PEM1 $PEM2
Generating a 1024 bit RSA private key
........++++++
..............................++++++
writing new private key to '/tmp/openssl.wc3819'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:AZ
Locality Name (eg, city) [Newbury]:Tempe
Organization Name (eg, company) [My Company Ltd]:Self
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:mail.home.local
Email Address []:myself@yahoo.com


Next we need to make some edits to the sendmail.mc file. cd to /etc/mail and open the file with your favourite editor. The following lines should be edited or added to match your configuration and/or connection information to your ISP. Note that dnl at the front of a line indicates a comment. This should be removed from the beginning of any lines that are edited.

define(`SMART_HOST', `smtp.att.yahoo.com')dnl <==put your ISP's smtp server here

DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl <==uncomment this line


Now we need to set up the login information for your ISP’s smtp server. In the /etc/mail directory perform the following:

mkdir auth
chmod 700 auth
cd auth
vi client-info

Add the following line to the client-info file:

AuthInfo:your.isp.net "U:root" "I:user" "P:password"

Repace user with your ISP username and password with your smtp password. Save and close the file and perform the following:

makemap hash client-info < client-info
chmod 600 client-info*
cd ..

Now issue the following command so that everything is compile as sendmail likes it:

make -C /etc/mail

Last edit the following file and make sure that it contains the following two lines:

vi /usr/lib/sasl2/Sendmail.conf
pwcheck_method:saslauthd <==make sure that these two lines are in the file
mech_list: plain login


If you are using tcpwrappers as I have suggested in the past add the following line to hosts.allow. Change the ip configuration to match your setup:

vi /etc/hosts.allow
sendmail: 172.16.

Now it’s time to test. Make sure that the correct services are running:

/etc/init.d/sendmail start
/etc/init.d/saslauthd start


After starting check the log at /var/log/maillog. If you find any errors that contain `starttls’ then either something is wrong with the sendmail.pem file that you created or the saslauth daemon is not started. I had a situation once where something happened to the sendmail.pem file and recreating it solved the problem. Beyond that check your firewall, syntax in the sendmail.mc and hosts.allow and hosts.deny files.

Once everything is started cleanly open up your mail client. I used evolution for testing. Edit the preferences and use the settings for your sendmail server. For mine I used the IP address of the sendmail server, check “Server requires authentication”, set “Use secure connection” to SSL encryption and entered the user name that I use to login to the sendmail server. Note that this is not your ISP username.

Now you should be able to send a test message out through the internet and receive it back through your ISP’s pop server.

Enjoy!

-j

There are many excellent 3rd party security tools out there for you to install on your system. Prior to installing these though you should review the tools that are already on your system. There is probably already a package included with the system that will accomplish what you need.

Why not use these tools? The major Linux distributions have gone to considerable expense to test these tools and make sure that they will not break anything on your system. When you consider the many 3rd party applications that are certified for a distribution such as Lotus Domino and JBoss this becomes even more critical. These applications are generally installed because they are mission critical. You don’t want to install a non certified security application only to find that it breaks or creates a security flaw in your certified mission critical application. Don’t do this.

A pet peeve of mine has always been the idea of “point and click and know not what I just did” that many administrators perform. While this seems to be more prevalent in the Windows world it exists in the *nix world as well. Generally the idea of text configuration files can overcome this but not always. Take, for example, the website securecentos.com (not affiliated with CentOS). One of the things that they want you to do is patch your kernel with a patch from http://www.grsecurity.com/. Doing something like this should raise a red flag immediately. Do you know what the patch is fixing and/or how it is making your machine more secure? If you can’t answer yes to this then don’t do it with this or any other patch except one from your vendor.

Aside from that when your vendor releases a kernel update you are going to have to go and redo the whole process again. This can quite quickly become heavy with administrative costs. If your machines are duplicated across the network now you have to go and install this on all of them. And again when you run a kernel update. Don’t do this.

You should never download a configuration file that affects the core of your machine without knowing exactly what it does. Using the same site above they have many configuration files that they want you to download and put into production on your machine(s). There is even a sysctl.conf file which affects many core processes of your machine and how they operate. At the time of this post comments in this file are non existent. This amounts to the notion of “point and click and know not what I just did” mentioned above. Don’t do this.

I don’t mean to single out securecentos.com. It just happens to be the one that I ran across today among the many out there asking administrators to do some things that they should think twice about.. I’m sure that they mean well. If I got out my sysctl manual I could find out what each of those changes would to do to my machine. However I’m not going to..if they want me to use their product/advice then those should be clearly documented either in the file or with a url embedded in the file that leads to that information.

Be smart with your machines! Don’t go putting configuration files in service, clicking on buttons that affect the security or core services of your machine or installing 3rd party applications that may already have the equivalent tested on your machine without knowing exactly what other files and applications they are going to affect.

-j

Red Hat released version 5.3 on January 21st of this year. The CentOS developers generally follow with a CentOS release about 3-5 weeks after Red Hat. This should put the release as generally available around March 1st.

We can expect to see some very nice feature enhancements on this release. NetWorkManager and wpa_supplicant have a whole host of updates listed. This means improved wireless security and better driver support. For those of us using Broadcom wireless drivers the b43 driver from linuxwireless.org has been backported. Following the links on that page should lead you to the proper firmware as well.

The new ext4 filesystem is also incuded in the new release. Laptop users like myself will be glad to know that anaconda now supports encrypted block devices during installation. Red Hat continues their commitment to Xen and has released many updates for virtualizaton including support for up to 126 CPUs in the x86_64 Xen-based hypervisor (up to 32 CPUs per virtual server) and support for up to 1TB memory per host on x86_64 (up to 80GB per virtual server).

Other enhancements include 802.1q VLAN tagging support for kickstart, iSCSI installation and boot support, ability to install Xen and KVM guests and for fibre channel users Emulex FCoE HBA support through the lpfc driver and QLogic FCoE HBA support through qla2xxx driver. See a full list of new features here.

With all of these new enhancements desktop users and server administrators are sure to be pleased.

-j

The OS that I use is Centos 5.2 with the native Red Hat Xen virtualization utilities. This should also be good for RHEL 5.2 as well. I downloaded and installed openfiler-2.3-x86.tar.gz as the NAS frontend for my Xen virtual server. The information that I provide here is good for that version. I have a feeling that it may change some from version to version as many of the config files that I found were very similar but enough off to keep the machine from booting.

I use physical volumes for all of my Xen virtual machines. All of this should apply except for the way that file images are defined in the config file.

You will need approximately 3 GB of disk space for the Openfiler front end and swap. You probably should add a little more in case you find that you want some applications installed that don’t come with Openfiler. By default Openfiler will use about 1 GB of that space for swap.

[root@openfiler ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 6.0G 2.3G 3.4G 40% /
none 130M 0 130M 0% /dev/shm


[root@openfiler ~]# free
total used free shared buffers cached
Mem: 264596 218432 46164 0 84448 55240
-/+ buffers/cache: 78744 185852
Swap: 1048568 0 1048568


After deciding how much disk space that you want to use create it using your desired method-physical disk or file image. Once you have it created format it with ext3 or with your favorite file system. Now mount it and extract the tar ball from where you saved it into mounted directory. I created the directory openfiler under /mnt and mounted the disk there.

lvcreate -L+6G -n openfiler linux-virtuals.hdd1
mkfs -j -L openfiler /dev/linux-virtuals.hdd1/openfiler
mkdir /mnt/openfiler
mount /dev/linux-virtuals.hdd1/openfiler /mnt/openfiler
cd /mnt/openfiler
tar xzvf /srv/secure/openfiler-2.3-x86.tar.gz #path to saved tarball


You need to create a directory to hold the boot files on your Xen host machine. I called mine boot-openfiler. Copy all of the files from /mnt/openfiler/boot/* to /boot-openfiler. Next copy the openfiler kernel modules to /lib/modules.

mkdir /boot-openfiler
cp -a /mnt/openfiler/boot/* /boot-openfiler/
cp -a /mnt/openfiler/lib/modules/2.6.21.7-3.20.smp.pae.gcc3.4.x86.i686.xen.domU /lib/modules/


Now we need to create our openfiler NAS config file. cd to /etc/xen and create the config file for openfiler. You can use the one shown below as a template. Be sure that you create a unique uuid, MAC address and adjust your disk paths.

cd /etc/xen
vim openfiler

Notice that the kernel= and and ramdisk= point to the /mnt/openfiler/boot/* files that we copied point to the boot-openfiler directory that we created. You will also need to add your root=xvda1 ro to the config file. The “phy:/dev/sda,xvdb,w” entry that you see above is the 1TB SimpleTech external drive for which I am using the Openfiler NAS frontend.

Now unmount the partition that you mounted for the Openfiler files and start the domain with the typical xm create -c openfiler or the virsh command.

A cautionary note: Don’t copy the config file from above. WordPress seems to do something to the lines and they don’t start and end correctly ie. they won’t be parsed correctly when starting the domain.

Have fun with your new Openfile NAS!

-j

At this point you should have 2 interfaces in your domU. One should be facing the internet and have an IP Address assigned from your ISP. The other should be a typical Xen interface with a static IP that connects to the rest of your network.

To start off our iptables network let’s open up the system-config-security application and make sure that iptables is enabled. Go ahead and close this once that is done. That should create a standard Red Hat\CentOS firewall setup as a starting point. You can check this by issuing the command:

iptables -L


Notice the chain that Red Hat\Centos adds to the typical iptables -L output. It is referenced by the input and forward chains. Generally when you put in a reference to the input chain you need a corresponding reference to the forward chain. This extra chain is the one that we will work with the most. Since it is referenced by both the forward and input chains we don’t need to put corresponding rules in both chains It is called:

RH-Firewall-1-INPUT


The first thing that we want to do is get the machines on our network out to the internet. We do this by using the nat table and the postrouting chain. This is the command to accomplish that:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

This will let any internet request from your internal network access the internet. My internet facing NIC is eth1. Your’s may vary. Notice the -o eth1. This indicates that it is looking for outbound packets on eth1.

By default anything coming in from the internet is blocked. You’re probably going to want to let ssh and maybe openvpn come in from the internet. The solution that I use for this is to use domUs behind the firewall so that these requests land there rather than on the firewall machine. Here is how to setup an inbound request and have it directed to the landing server. From there you can go where you need on the network.

##ssh
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 22 -j DNAT --to 172.16.0.201
##openvpn
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1194 -j DNAT --to 172.16.0.201

Any port that you need uses the exact same syntax except for the port number.

We also need to enable port forwarding so that it will survive a reboot. Use the following commands to enable it for your current session and set it up to survive a reboot:

[root@virtual-host ~]# sysctl -w net.ipv4.ip_forward=1
[root@virtual-host ~]# sysctl -p
#output
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 4294967295
kernel.shmall = 268435456
[root@virtual-host ~]#

As we can see from the first line under #output ip forwarding is set to 1 which means that it is turned on.

Note that if you go back and use any of the firewall GUIs provided you will lose all of the settings that used the nat table. I suggest that you stick with the command line after making your initial setup.

Here is what my iptables output looks like:

[root@fw0 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:servicetag
ACCEPT udp -- anywhere anywhere udp dpt:servicetag

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
DROP tcp -- yktgi01e0-s4.watson.ibm.com anywhere tcp dpt:https
DROP tcp -- yktgi01e0-s4.watson.ibm.com anywhere tcp dpt:http
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW,RELATED,ESTABLISHED udp dpt:servicetag
ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:servicetag
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:domain
ACCEPT udp -- anywhere anywhere state NEW udp dpt:domain
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:smtp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
[root@fw0 ~]#

The two drops that you see at the top of the input chain are from somebody that kept hitting on my web server. Usually if you want to put a drop in against a specific target your will want to insert (I) it at the top of the chain like so:

iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport 80 --source 11.22.33.444 -j DROP

The 1 just after INPUT instructs iptables to make that the first rule in the chain. Since both the input and forward chains are reference by the RH-Firewall-1-INPUT chain we don't have to concern ourselves with putting the same rule in the forward chain.

I hope this helps you get started with your domU firewall.

-j

The first thing necessary to setting up a domU firewall that is exposed to the internet is to “hide” an interface from dom0 and import it into the domU firewall machine. To start we need to do a few things. Ultimately this is going to cause of reboot of dom0 so consider if this is feasible for your situation.

Let’s get started. First we need to get some numbers from the interface To do this use the lspci command.

[root@virtual-host ~]# lspci |grep -i ethernet
==>01:02.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
01:02.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
01:06.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)

As you can see I have three interfaces on this machine. The marked interface requires an entry into modprobe.conf and the xen firewall configuration file.

##modprobe.conf
options pciback hide=(01:02.0)

##xen firewall configuration
pci = [ "01:02.0" ]


Now we need to use the lspci -n command and use this entry in the xend-pci-permissive.sxp file under /etc/xen.

[root@virtual-host xen]# lspci -n
==>01:02.0 0200: 8086:1079 (rev 03)
01:02.1 0200: 8086:1079 (rev 03)
1:06.0 0200: 8086:100e (rev 02)

Match the pci numbers from the lspci command to find the correct line. You’ll want the last 8 characters of this line. In the code above we want the 8086:1079 part of the output.

Open the xend-pci-permissive.sxp and make an entry like the following:

(unconstrained_dev_ids
('8086:1079')
)


Once we have this done we need to make a new initrd image that preloads the pciback module. Before running the following code you should make a copy of your current initrd. If you run into problems you can use this to replace the one that you created and try again. Use the following code to create the new initrd:

cd /boot
mkinitrd -f --preload pciback initrd-$(uname -r).img $(uname -r)


After creating the new initrd it’s time to reboot and check your work.

Once dom0 is up we need to look for certain entries in /var/log/messages:

[root@virtual-host ~]# grep pciback /var/log/messages
vpci: 0000:01:02.0: assign to virtual slot 0
virtual-host kernel: pciback 0000:01:02.0: seizing device
virtual-host kernel: pciback 0000:01:02.0: enabling permissive mode configuration space accesses!
virtual-host kernel: pciback 0000:01:02.0: permissive mode is potentially unsafe!
virtual-host kernel: pciback: vpci: 0000:01:02.0: assign to virtual slot 0


Once you see that the device is seized and assigned to a virtual slot check your firewall machine to make sure it is getting an ip from your ISP as well as connected to your local lan IP.

[root@fw0 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3E:36:73:82
inet addr:172.16.0.254 Bcast:172.16.255.255 Mask:255.255.0.0
inet6 addr: fe80::216:3eff:fe36:7382/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:548690 errors:0 dropped:0 overruns:0 frame:0
TX packets:291190 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:486044371 (463.5 MiB) TX bytes:47023339 (44.8 MiB)

collisions:0 txqueuelen:100
RX bytes:50257788 (47.9 MiB) TX bytes:487593757 (465.0 MiB)
Base address:0xb400 Memory:fea40000-fea60000


As you can see from the above output eth0 is connected to my lan and eth1 has received it’s internet address so that we are connected to the internet. The OS (Red Hat/CentOS) should create the entry for eth1 without any input on your part.

Please read my next post for setting up iptables in your domU.

-j

Running this command however gave some strange output, primarily ? marks. I thought this was a little strange but had other things that I needed to do at the time and decided that I would look into it later.

This weekend was that time. Let me say that I use SELinux on my Red Hat and CentOS machines and think that it is a very good way to help secure a machine. However it is anything but intuitive. If it weren’t for some very good documentation at Red Hat I probably never would have been successful at using this security tool. Mind you I’m no guru with it but I have six servers using it and I know how to troubleshoot SeLinux problems.

Which brings me to the part about Ubuntu and SELinux that I find disturbing. Doing some Google searching I ran across two pages regarding Ubuntu and SELinux. Both of them had no usable information in them other than how to install SELinux. Nothing about what to expect, how to troubleshoot, what a context or a boolean is nor did it mention if Ubuntu provided any troubleshoooting tools like setroubleshoot. You can find these two pages here and here.

The documentation only warned that SELinux is for experienced users. While that is an understatement how do they expect people to start using it to protect their machines? It would seem to indicate that they have no real interest in their users having the ability to use SELinux. I personally think that is a shame. I also believe that it is going to hurt their efforts at becoming enterprise ready especially with their server product. I certainly won’t be installing Ubuntu on any of my critical machines.

-j

Moving on I mentioned that my MySQL server is on one box and my web server on another. One of the applications that I use is KPlaylist. This is a streaming server for mp3s, movies or just about anything you want to stream. My first snag was getting it to log into MySQL and create the database.

After about an hour of looking for normal causes I decided to turn on setroubleshoot. This is a great tool when looking for SELinux problems. After I turned it on I found this in /var/log/messages:

Nov 20 15:40:47 web setroubleshoot: SELinux is preventing the http daemon from connecting to network port 3306 For complete SELinux messages. run sealert -l 65919ff0-ddd1-4a4b-801d-f54023da86ac

So then I ran the sealert command shown in the message:

sealert -l 65919ff0-ddd1-4a4b-801d-f54023da86ac

This gave me the following along with some other information:

setsebool -P httpd_can_network_connect=1


Voila! My problem was fixed. Well almost. I then discovered that iptables was blocking the port. After opening the port using the gui “system-config-securitylevel” all was well. KPLaylist installed it’s database just like it was supposed to.

My next hurdle was getting the nfs share on the music-repo server to mount on to the web server. Checking for another sealert I found one on the webserver called

Nov 20 23:57:33 web setroubleshoot: SELinux prevented the http daemon from reading files stored on a NFS filesytem. For complete SELinux messages. run sealert -l f76bd0be-d375-436f-9c09-2086da0d7a39

After running this I got the following information:

setsebool -P httpd_use_nfs=1


Well this didn’t totally solve my problem but I did notice that things were getting fixed with the setsebool command. I went looking around the net to see what I could learn about it.

What I learned is that if you are having a problem with a service is that you should run the command getsebool -a |grep someservice. I decided to try that with NFS and this is what I got:

[root@music-repo ~]# getsebool -a |grep nfs
allow_ftpd_use_nfs --> off
allow_nfsd_anon_write --> off
nfs_export_all_ro --> on
nfs_export_all_rw --> on
nfsd_disable_trans --> off
samba_share_nfs --> off
use_nfs_home_dirs --> off
[root@music-repo ~]#

The last line was what I found interesting. I had originally had my music directory on the music-repo machine at the root of the system. My thought was OK let’s create a user with a home directory and enable that boolean. I created a user on the musiic-repo system called apache and moved the /music directory into /home/apache. I then ran the command:

setsebool -P use_nfs_home_dirs=on


I also moved my music directory that I was mounting to under /var/www which is apache’s home and ran the same command. Now everything was connected and working like it is supposed to be.

A note of interest to those of you who would prefer a gui..you should install policycoreutils-gui. This will give you a nice gui called system-config-selinux. In this gui you can browse through everthing SELinux has to say and can change.

Now to get that setup as a share for the Windows users so that they can store their music and get it backed up.

-j

First up are the /var/log/audit/audit.log, /var/log/security and /var/log/messages. If selinux is set to enforcing and you’ve just installed a new application or created a file or directory that is not allowing proper access these three files are the place to go. Before you do this make sure the following applications are installed:
setroubleshoot.noarch
setroubleshoot-plugins.noarch
setroubleshoot-server.noarch

After installing these make sure that you start the setroubleshoot application and set it to start on reboot:

/etc/init.d/setroubleshoot start
Starting setroubleshootd: [ OK ]
chkconfig setroubleshoot on


Watch the logs in real time as you attempt to access the application, file or directory like this:

cd /var/logs
tail -f security audit/audit.log messages

After doing this hit enter three times to give you some white space between the old messages and the new ones that are generated. If selinux is giving you a problem you will see something like the following in the messages log:

Nov 5 08:18:44 centos5-dev setroubleshoot: SELinux is preventing access to files with the label, file_t. For complete SELinux messages. run sealert -l d102b5a4-ac6f-470f-aa34-55ac37dafa37


To find out not only what is going on but how to fix it run the sealert -l d102b5a4-ac6f-470f-aa34-55ac37dafa37 command described in the message.

[root@centos5-dev ~]# sealert -l d102b5a4-ac6f-470f-aa34-55ac37dafa37

host=centos5-dev.hendricks.org type=SYSCALL msg=audit(1225891119.851:12): arch=40000003 syscall=5 success=no exit=-13 a0=b7fb2b4b a1=0 a2=bfd8a2b4 a3=8 items=0 ppid=2633 pid=2634 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hpssd.py" exe="/bin/env" subj=system_u:system_r:hplip_t:s0 key=(null)
[root@centos5-dev ~]#

The part that we are interested in is under the above heading Allowing Access: You can execute the following command as root to relabel your computer system:
"touch /.autorelabel; reboot"
When we run this command this will fix our problem. Note that these problems could run from accessing html pages to allowing a public web directory in your home directory.

Next up we have the command:

chcon --reference

Lets say you are using your localhost as your web server. You decide that you want to add some virtual hosts. You then add the virtual host directories outside of the normal /var/www/html directory. You build your virtual hosts but now you can’t access them. Watching your messages you see that this is definitely an selinux problem. Using the above command we can fix our problem like this:

chcon --reference /var/www/html /srv/www/vhosts #This will fix the selinux properties on the root directory of the virtual hosts
chcon -- reference /var/www/html/* /srv/www/vhosts/* # This will fix the properties on the files in case they are different from the directory

This code references the contexts of the given files or directories and applies them to the new files and directories. Now every time that you add a file or directory under /srv/www/vhosts it will get the proper selinux context.

The last way that we are going to discuss is restorecon. Taking the above scenario under either of the directories you find that some files or directories did not pick up the correct context or maybe none at all. Easy enough to fix:

restorecon /var/www/html

The reason this works is because the restorecon looks at the current contexts of the other files and directories and applies that context to the ones with the incorrect or no context.

There you have it. Keep your sanity and still use SELinux.

-j

Ken says (paraphrased)

1. Built-in Paravirtualization – I want a distribution that is paravirtualized–that is to say, a distribution that comes out of the box ready to give you the virtualization you need as a hypervisor OS

What’s wrong with CentOS or Red Hat. They both come ready with paravirtualization. I am running on the laptop where I am writing this. And I firmly believe that they are considered a major distribution.

2. Applications on Demand – Instead of installing all the applications I want, or think I want, up front, I’d like to have the opportunity to install applications on demand. I want the icons already there as options but when I click the icon for the first time, the application installs, with all its damn dependencies and I have my application.

It is my opinion that Open Source Developers are some of the best in the world. I am sure that they could satisfy Ken’s desire for this. Just one small problem-not everyone is going to want the same applications that Ken wants. The developers are good..but they are not mind readers.

3. Microsoft Office – No, I’m not selling out here and I know about OpenOffice.org but come on, think of the user base that would come from that port. Linux users are typically anti-Microsoft but how many would still use Microsoft Office? And, how many companies might convert to Linux if MS Office were available for it? I don’t know, maybe it’s just me.

Ken, I think it is just you. People are moving away from Microsoft Office for two reasons: licensing cost and open document format. Remember all of the hullabaloo a few months ago over open document format because Microsoft did not want to adhere to any standard that would allow people to translate their documents into another format? Besides if you really wanted it Crossover Office at less than $50 should fit your meager budget and allow you to use Microsoft Office-that is if the license cost did not drive it over your budget.

4. A Non-Windows-Looking-Acting-Emulating Window Manager – Every Window Manager with the exception of maybe XFCE (which looks like MacOS X) looks like, and tries to emulate, Windows. Can’t someone come up with a different schema? Do we have to wait for Microsoft to come up with something so that we can copy it? Come on, get creative.

For the life of me I cannot get my Gnome desktop to look like a Windows desktop let alone act like it.

Plug in a peripheral and nothing happens–nothing visible at least. Why should I have to open a Terminal Window and mount a flash drive disk that I just stuck in my computer? Why can’t Linux mount it and open it to show me the contents?

Are you using a recent version of Linux? My digital camera and thumb drives all open a window when they are plugged in.

As I said, Linux is fine for hackabee like me but we want regular people to want to use it too, right?

Using Linux, except in very rare situations is no different than using a new version of Windows. There is a learning curve about where things are placed, how to use the applications and so on. It bugs me a little that I don’t use the command line as much as I used to. As an administrator it is definitely a skill that I do not want to lose.

You can edit photos, create documents and spreadsheets, listen to music, browse the web, get email and so on with Linux. And it takes no more work to do it than it does with Windows. All without the command line. This is more than suitable for most users, grandma and grandpa included.

-j