Diary of Fedora 14 Install and Migration from Fedora 8

Diary of Fedora 14 Install and migration from Fedora 8 21 January 2011 RWR Helpful Internet resources: (F14RN): Fedora 14 release notes: http://docs.fedoraproject.org/en-US/Fedora/14/html/Release_Notes/ (F14IG): Fedora 14 Installation guide: http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/index.html (SWI): Server-World Info web pages (very good for configuring a server): http://www.server-world.info/en/note?os=Fedora_14&p=install (MJMsIG): Mauriat Miranda's Personal Installation Guide: http://www.mjmwired.net/resources/mjm-fedora-f14.html (UFFAQ): The Unofficial Fedora FAQ: http://www.fedorafaq.org/ Various Fedora Community Web Sites/Forums with links here: http://fedoraproject.org/wiki/CommunityWebsites My Post-install notes (My upgrade from FC4 to FC6): http://host.domain.net/FC6_Post-install.pdf My Post-install notes for migration from FC6 to F8: http://host.domain.net/postinstallF8am.pdf

Note: The Computer Hardware Specifications of the “new” host: Dell Dimension 4600 Series (Purchased May 2004) X86 Intel Pentium 4 Processor 2.8GHz 1.5GB SDRAM Memory (upgraded) 0.333GHz Intel 82865G Graphics Controller Integrated Audio Dell Wireless Keyboard and Mouse Two Hard Drives: Primary Master: IDE1: 500GB Western Digital Co. WD5000AAKB-00H8A0 (Fresh Fedora 14 install) Primary Slave: IDE2: 320GB Western Digital Co. WD3200AAJB-00WGA0 (Win XP Prof. SP3)

Note: Both drives are installed with the jumper set in the Cable Select (CS) position with The WD 500GB drive is in the 1st IDE position and WD 320 GB Drive in the 2nd IDE position. This sets the Master/Slave relationship as described above. (Originally, the 320 GB Win XP Drive was in Master position and the Fresh Fedora 14 install was done from the Install DVD on the 500GB drive in the slave position. The Fedora Drive has three partitions: A small Boot Partition with grub, a 3GB- Swap partition, and a large LVM containing the Fedora 14 System. I wanted to set up a dual boot system with Fedora 14 as the default and Win XP as an option. But the auto setup provided by the Fedora 14 Install DVD did not work. The Bios always started the boot with the master drive and so the default was XP. I could not change this in the Bios. So I switched the drive positions to what is indicated above… Now, the grub boot menu came up … but the win XP option did not work. After a google search I found the way to get WinXP to boot from the Slave Drive. See: http://www.linuxquestions.org/linux/answers/Applications_GUI_Multimedia/Booting_Windows_on_second_HD_with_Grub Following the suggestion found in this URL, I copied the following four lines into the grub.conf file: title Windows XP map (hd0) (hd1) map (hd1) (hd0) chainloader (hd1,0)+1 This works! ) So I have a dual boot system: Fedora 14 and Windows XP, with Fedora 14 as the default. The Fedora 14 System was given the Name: chaoshome2 Placed on the local network at fixed IP address: 192.168.20.102 The old Fedora 8 System has the name ‘chaoshome’ and has fixed IP address: 192.168.20.101

Users were added to the Fedora 14 system such that they have identical user-ID numbers and Group-ID numbers in each system. Now, I should be able to use nfs (or samba) to mount file systems from Fedora 8 (chaoshome) onto mount positions on the Fedora 14 (chaoshome2) system and copy files preserving properties.

Fedora 14 Post-Install Actions

1. Set up "sudo":

Follow ref. MJMsIG (listed at top).

]$ su password:

]# echo 'username ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

------

2. Set up "yum":

I selected many programs for both desktop and server systems for install from the Fedora 14 Install DVD. I also chose a set of repositories for use by yum.

I followed MJMsIG; adding the yum fastmirror plugin.

$ sudo yum install yum-plugin-fastestmirror

------

3. Third party repositories

I followed MJMsIG, I set up the RPMFusion repositories:

$ sudo rpm -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release- stable.noarch.rpm

$ sudo rpm -ivh http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release- stable.noarch.rpm Note: these commands are all on one command line.

------

4. Updated newly installed F14 system.

By this time a pop-up window told me there were severa; updates available. I followed the prompts and the yum Software Updater updated the system. This only took a few minutes. So we know the automatic update system is working.

------

5. Repartitioned Windows XP drive

Hard Disk Drive /dev/sdb is a 300GiB (320 GB) hard drive that currently contains a single windows (XP Professional) boot partition (was Betty-1 PC) (used space is about 87 GiB out of 298 GiB). I want to shrink the windows partition and make the remaining space a second partition that can be mounted and used as backup space for the new Fedora system.

5.1. Installed Gparted on Fedora 14 system.

5.2. Unmounted /dev/sdb1 (mounted in fstab at /betty-1) and looked at /dev/sdb with Gparted.

5.3. Prepared /dev/sdb1 partition for shrinking by booting up XP and running the windows De-fragmentation program to clean and organize the used portion. Running Defrag twice got the entire used space moved to the front of the partition according the info reported by Defrag. Checked to make sure the windows partition still boots up cleanly....[OK].

5.4. Used Gparted to shrink the partition to about 177GiB leaving about 180 GiB unallocated. I was careful to not change the "Free space preceding" the partition ( which was 0 MiB) so as to protect the windows Master Boot Record. I left the "align to" set to MiB. Clicked on the check mark and "Apply" to start the operation. The process was completed successfully in less than 3 min. Rebooted into win XP ... it automatically ran chkdisk and then booted up fine. Did a reboot into windows XP and it came up cleanly.

5.5. Used Gparted to create a new partition in the remaining unallocated space (180.90 GiB). I chose the defaults except for "File system", which I set to "ntfs" (so the partition would be visible to windows XP) and label: bkup. Clicked the check mark and "Apply" to start the operation. The operation was completed successfully in 6 sec.

Now /dev/sdb has two primary partitions: /dev/sdb1 ntfs BETTY-1 117.19 GiB size 86.69 GiB used boot /dev/sdb2 ntfs bkup 180.90 GiB size 0 GiB used

I booted into Windows XP and it sees the new partition as F:

I booted into Fedora 14 and changed /etc/fstab to mount the new partition at /bkups.

------

6. Set up samba for file sharing with Windows computers

The samba system was installed from the F14 Install DVD.

I essentially followed MJMsIG. The settings for SELinux and Firewall were important. All samba server items were marked as trusted. I used the Administration GUI (System > Administration > Samba) to set up a share directory and the samba user username with password to match the windows user username and password. After some minor tweaks, it works.

I can see the chaoshome2 system’s shared directory and user username’s home directory from all windows PCs when logged in as username, but, as in the past, I was not able to see all the Windows PCs and their shared directories from the Fedora 14 System. I found a solution to this latter problem here: http://www.vanwykipedia.com/doku.php?id=technical:netbios Must edit the /etc/nsswitch.conf file and add ‘win’ to the hosts: line as described in the URL above. After making the change I rebooted the system to make sure that all network services were updated. Now Fedora 14 sees all PCs (but still cannot browse my windows vista system). But I can get access to all Windows files by several methods, including mounting.

See below examples of testing and mounting files from Windows PCs in Fedora 14.

Use command “smbtree” to get a listing of all Windows PCs and other Samba file systems available on the network:

$ smbtree Enter username's password: ********** CHAOSNET \\ROLLINS2 Home Dell XPS 420 \\ROLLINS2\Manuals \\ROLLINS2\IPC$ Remote IPC \\ROLLINS2\H \\CHAOSHOME2 Samba Server Version 3.5.6-71.fc14 \\CHAOSHOME2\username Home Directories \\CHAOSHOME2\IPC$ IPC Service (Samba Server Version 3.5.6-71.fc14) \\CHAOSHOME2\public public_Share on Chaoshome2 \\CHAOSHOME Samba Server 3.0.33-0.fc8 \\CHAOSHOME\username Home Directoris \\CHAOSHOME\IPC$ IPC Service (Samba Server 3.0.33-0.fc8) \\CHAOSHOME\public Public Stuff $

Mounting a windows file system (note: the mount point must already exist)

$ sudo mount -t cifs -o username=username, //ROLLINS2/H /mnt/windows Password: ********** $

The above mounted file system is only writeable by root. Also, one can place the credentials in a file with two lines: username=username password=**********

Place the above two lines in a secure location readable only by root; say “/root/username”. Then can pass the credentials and give a user write permissions within the mount command:

$ sudo mount -t cifs -o credentials=/root/usernamescred,file_mode=0775,dir_mode=0775,uid=username,gid=username //ROLLINS2/H /mnt/windows

All on one line, of course. Note: the “-o” options are separated by “,” and some of these options only apply to cifs file systems. Now the user ‘username’ has permission to write on the mounted file system.

$ $ ls -dl /mnt/windows drwxrwxr-x. 1 username username 4096 Feb 7 22:14 /mnt/windows $

------

7. Setup NFS to work through a firewall.

The URL for the Fedora Documentation of the Network File System (NFS): http://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/ch-nfs.html

NFS was installed from the Install DVD. According to the Fedora Doc. (above URL) the required services are: nsf, nsflock, and rpcbind. (The portmap service used in earlier Fedora versions is replaced by rpcbind in Fedora 14.)

[username@chaoshome2 ~]$ sudo service nfs status rpc.svcgssd is stopped rpc.mountd (pid 19903) is running... nfsd (pid 19900 19899 19898 19897 19896 19895 19894 19893) is running... rpc.rquotad (pid 19887) is running... [username@chaoshome2 ~]$ sudo chkconfig --list rpcsvcgssd rpcsvcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off [username@chaoshome2 ~]$ sudo chkconfig --level 35 rpcsvcgssd on

Apparently the service rpcsvcgssd does not need to be running in Fedora 14. (I did not find the service “rpcsvcgssd” mentioned in section 9 of the Fedora 14 Doc notes.) Ultimately, NFS is working, so I guess this is OK. I only use NFS mounts on special occasions and when finished I use umount to remove the link to the shared filesystem.

[username@chaoshome2 ~]$ sudo service nfslock status rpc.statd (pid 1282) is running... [username@chaoshome2 ~]$ sudo service rpcbind status rpcbind (pid 1143) is running... [username@chaoshome2 ~]$

OK, everything is installed and running now. I needeed to make sure these services are started at boot time:

[username@chaoshome2 ~]$ sudo chkconfig --list nfs nfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off [username@chaoshome2 ~]$ sudo chkconfig --list nfslock nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off [username@chaoshome2 ~]$ sudo chkconfig --list rpcbind rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off

All three services are on in runlevels 3 and 5, which is all I care about.

Nevertheless, I could not make contact with the Fedora 8 system without turning off the firewall on the Fedora 14 system by using

$ sudo service iptables stop

The Fedora Documentation section 9.6.3 speaks directly to this problem, but does not spell out explicitly how to fix things in the iptables file. I found the following URL that explains explicitly how to allow NFS to work through the firewall: http://www.cyberciti.biz/faq/centos-fedora-rhel-iptables-open-nfs-server-ports/

The point seems to be that NFS services choose what ports to use at random (from those that are free) when the service is started. Thus, in order to open the correct ports we must fix the ports NFS uses. There are six ports involved and the nfs configuration is fixed by editing the file: /etc/sysconfig/nfs

$ sudo vi /etc/sysconfig/nfs

I simply uncommented the lines:

LOCKD_TCPPORT=32803 LOCKD_UDPPORT=32769 MOUNTD_PORT=892 RQUOTAD_PORT=875 STATD_PORT=662 STATD_OUTGOING_PORT=2020

I then restarted the services:

$ sudo service nfs restart $ sudo service rpcsvcgssd restart

I can check to see what ports are used by nfs by executing “rpcinfo –p” and that verified the above six ports along with port 2049 (always the default port used by nfs itself) are used and also what protocol (tcp or udp) is used by each. Now to modify the iptables to open these ports I edited the file:

$ sudo vi /etc/sysconfig/iptables

I then added the following lines:

-A INPUT -s 192.168.20.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT -A INPUT -s 192.168.20.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT

I then restarted the iptables:

$ sudo service iptables restart

************************************************************************************************ Update: I found out the hard way that these additions to the iptables are wiped out if you subsequently us the Firewall GUI under System > Administration > Firewall . Hence, I saved the iptables file as iptables.RWR when corrected. ************************************************************************************************

Now I must share the desired filesystem. For example, say I want to share the “/public” directory on the Fedora 8 system (chaoshome) with any other Fedora 14 system in read-write mode and also (actually this is what I really want to do) share the entire file Fedora 8 filesystem (with new Fedora 14 on chaoshome2) in read-only mode. That is done by adding two lines to the “/etc/exports” file (on the Fedora 8 system) (one line for each filesystem client pair).

On the Fedora 8 system (chaoshome) $ sudo vi /etc/exports I placed the following two lines in the file:

/public 192.168.20.0/255.255.255.0(rw,no_subtree_check) / chaoshome2(ro,root_squash)

(Use “man exports” for an explanation of the options. Only rw is not a default value)

Then, to register all the shares listed in “/etc/exports”, I executed the exportfs command with the –r option: On chaoshome: $ exportfs -r

I can check to see that all is as I expect by executing the command “exportfs –v” to show all currently exported filesystems on chaoshome: $ exportfs -v / chaoshome2(ro,wdelay,root_squash,no_subtree_check) /public 192.168.20.0/255.255.255.0(rw,wdelay,root_squash,no_subtree_check) $

Note that all important options (including default options) are shown. Also note that, with these options, the permissions on the filesystems mounted are preserved so (if uids match on the two systems) normal users (not root) have the same access to the mounted filesystem as they do on the original host.

Now, I went to chaoshome2 and requested a list of possible shares from chaoshome: (on chaoshome2) $ showmount -e chaoshome Export list for chaoshome: /public 192.168.20.0/255.255.255.0 / chaoshome2 $

To NFS mount the entire chaoshome filesystem at point /fedora8 on chaoshome2 I executed the mount command: (on chaoshome2) $ sudo mount -t nfs chaoshome:/ /fedora8 (of course the mount point “/fedora8” must already exist on chaoshome2)

Now I can copy files from the Fedora 8 system over to the Fedora 14 system using “cp –pR …”.

When finished, I unmount the Fedora 8 filesystem using (on chaoshome2) $ sudo umount /fedora8

Update: I found that the option “root_squash” for the share of the “/” file system on chaoshome would not allow me access to all files and directories even as root when mounted on chaoshome2. [Detail: Interestingly, in order to get access (meaning to read) mounted files under these sharing options, I found “others” must have at least r – x permissions; r - - was not enough!?)]

I had to change the option to “no_root_squash”; so the line in the “/etc/exports” file on chaoshome is: / chaoshome2(ro,no_root_squash) After this modification of “/etc/exports” on chaoshome one must execute $ exportfs -r to make the change take effect After this change was made, I had access to everything when mounted on chaoshome2.

------

8. Set up ssh:

The sshd was already installed and running on the Fedora 14 system. I had previously worked to increase security and limit ssh access on the Fedora 8 system. So I edited /etc/ssh/sshd_config to make it agree with the same file on the FC8 system. I copied the original (using “cp –p …”) and also marked my changes from the original file with comments. Restarted sshd.

$ sudo service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ]

SSH uses port 22, so I set the router to forward port 22 from the outside internet through to chaoshome2, the new Fedora 14 computer. ------

9. Copy home directories over from Fedora 8.

First mounted the Fedora 8 filesystem on the Fedora 14 at mount point /fedora8:

[username@chaoshome2 ~]$ sudo mount -t nfs chaoshome:/ /fedora8 [username@chaoshome2 ~]$

From the monitor, I used the GUI file manager (Nautilus) to open “/home/username” and “/fedora8/home/username and then drag and drop all directories and files(including .* (hidden) files) that I thought not to be part of the F8 operating system. (I could have used the command line “cp -ipR /bkups/home/username /home/username” and then said "no" to most of the overwrite queries.)

Copy the links to some of my scripts that are in /usr/local/bin:

[username@chaoshome2 ~]$ sudo cp -ipR /fedora8/usr/local/bin/* /usr/local/bin/

------

10. Set up Evolution GUI for local mail; make root email delivered to username.

Set up Evolution: Set up Evolution GUI for receiving so it would allow me to read my local mail. Opened Evolution and it led me through the setup procedure. There are several steps where the correct response was not immediately clear to me. I found the following choices to work: Email address: username@localhost Receiving mail: local delivery Path: /var/spool/mail/username Send mail using: sendmail

Have all mail sent to root forwarded directly to me: $ sudo vi /etc/aliases Changed last line of /etc/aliases file to read: root username

Then use the new information in /etc/aliases file to make a new aliases.db: $ sudo newaliases

Tested the above by using Evolution to compose and send a test email to root@localhost

------

11. Installed Logwatch program

I used the System > Administration > Add/Remove Software to install logwatch-7.3.6-59.fc14.

This monitors various security/system logs and mails a daily report to root. The default configuration file is “/usr/share/logwatch/default.conf/logwatch.conf” The local changes in the configuration are supposed to go here: /etc/logwatch/conf/logwatch.conf I just used the default settings.

Checked /etc/cron.daily to see that logwatch is on the daily list of things done by cron.

Update: The standard logwatch email arrived the next day….so logwatch appears to be working.

------

12. Installed Denyhosts using yum:

[username@chaoshome2 ~]$ sudo yum install denyhosts . . . Installed: denyhosts.noarch 0:2.6-20.fc14

Complete!

Compared the new /etc/denyhosts.conf with my /fedora8/etc/denyhosts.conf and found them to agree … thus must be using the default setup. Now need to start denyhosts and have it running automatically upon reboot:

[username@chaoshome2 ~]$ sudo chkconfig --list denyhosts denyhosts 0:off 1:off 2:off 3:off 4:off 5:off 6:off [username@chaoshome2 ~]$ sudo chkconfig --level 35 denyhosts on [username@chaoshome2 ~]$ sudo chkconfig --list denyhosts denyhosts 0:off 1:off 2:off 3:on 4:off 5:on 6:off [username@chaoshome2 ~]$ sudo service denyhosts start Starting denyhosts: [ OK ] [username@chaoshome2 ~]$

------

13. Migrate and configure Apache (httpd including ssl, webdav, and webalizer):

All the necessary packages should have been installed from the DVD. As a check I ran the following and checked the output with the same command on chaoshome (the Fedora 8 system)

[username@chaoshome2 ~]$ rpm -qa |grep httpd httpd-2.2.17-1.fc14.i686 httpd-manual-2.2.17-1.fc14.noarch system-config-httpd-1.5.2-2.fc14.noarch httpd-tools-2.2.17-1.fc14.i686 [username@chaoshome2 ~]$ rpm -qa |grep ssl qca-ossl-2.0.0-0.10.beta3.fc14.i686 nss_compat_ossl-0.9.6-1.fc13.i686 mod_ssl-2.2.17-1.fc14.i686 docbook-style-dsssl-1.79-11.fc14.noarch openssl-devel-1.0.0c-1.fc14.i686 openssl-1.0.0c-1.fc14.i686 [username@chaoshome2 ~]$ rpm -qa |grep dav cadaver-0.23.3-1.fc13.i686 [username@chaoshome2 ~]$ rpm -qa |grep webalizer webalizer-2.21_02-3.i686 [username@chaoshome2 ~]$ rpm -q --provides httpd |grep dav mod_dav = 2.2.17-1.fc14 mod_dav.so mod_dav_fs.so

It looks as if all packages we need for “httpd, ssl, webdav, and webalizer” are there (plus a new one, “qca-ossl”) The only package missing is “davical”, which I will need to install separately and describe in a later section.

The httpd configuration files are located in two places: /etc/httpd/conf  the main httpd configuration file /etc/httpd/conf.d  specialized configuration files (for ssl (https:/xxx.yyy), webalizer, etc.)

The main httpd.conf file contains the command “Include /etc/httpd/conf.d/*.conf” to read in specialized configurations for other programs like "webalizer", "ssl", etc. residing in the “/etc/httpd/conf.d” folder. Note: ssl.conf contains lines for “webdav” and “DAViCal”. Secure access using the apache web server (https://...) uses port 443 while ordinary (http://....) uses port 80 by convention.

Migrating the “/etc/httpd/conf/httpd.conf” file:

I first saved a copy of the original: [username@chaoshome2 ~]$ cd /etc/httpd/conf [username@chaoshome2 conf]$ ll total 52 -rw-r--r--. 1 root root 34417 Oct 27 06:01 httpd.conf -rw-r--r--. 1 root root 12958 Oct 27 06:04 magic [username@chaoshome2 conf]$ sudo cp -p httpd.conf httpd.conf.orig

It is a long way (many updates) from Fedora 8 to Fedora 14 so I decided not to simply copy the configuration files over, but instead I decided to look at them side by side and make modifications as necessary (marking each change with a comment.) I only list here the differences between the new and old unmodified files:

There were new modules loaded that were not in the old: LoadModule substitute_module modules/mod_substitute.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule disk_cache_module modules/mod_disk_cache.so in place of “file_cache……” LoadModule version_module modules/mod_version.so

There was no mem_cache_... modules entry in the new conf file but there was in the old.

Many more in the “modules not loaded by default” list in the new conf file: The following did not appear in the old file: #LoadModule authn_dbd_module modules/mod_authn_dbd.so #LoadModule cgid_module modules/mod_cgid.so #LoadModule dbd_module modules/mod_dbd.so #LoadModule dumpio_module modules/mod_dumpio.so #LoadModule filter_module modules/mod_filter.so #LoadModule ident_module modules/mod_ident.so #LoadModule log_forensic_module modules/mod_log_forensic.so #LoadModule unique_id_module modules/mod_unique_id.so

Line 457 in the modified file had changed since the Fedora 8 file.

Lines 831 – 835 (in modified file) had changed since Fedora 8. See note just below the lines: # # MIME-types for downloading Certificates and CRLs # AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl Note: These two lines were in the “/etc/httpd/conf.d/ssl.conf file in Fedora8 but were moved to /etc/httpd/conf/httpd.conf in Fedora14.

As I went through the httpd.conf file, modifications that I had made in the Fedora8 file were copied into the Fedora14 file.

Migrating the specialized httpd.conf configuration files:

To be on the safe side, I copied all the original files to a new folder: “/etc/httpd/conf.d.orig” [root@chaoshome2 username]# cp -ipR /etc/httpd/conf.d /etc/httpd/conf.d.orig

I then checked the “xxxx.conf” files in “/etc/httpd/conf.d” against the corresponding Fedora 8 “xxxx.conf” files and modified where needed. The only changes required were in “ssl.conf” and “webalizer.conf”. Note that “webalizer.conf” is set such that only computers in the local domain (192.168.20.*) are allowed access to the web server statistics web pages found at http://servername/usage

Now, I want to directly copy some file from chaoshome to chhaoshome2 so first mount the chaoshome (fedora8) file system: [root@chaoshome2 username]# mount -t nfs chaoshome:/ /fedora8  Mount Fedora 8

I copied the “passwd” directory in “/fedora8/etc/httpd” to “/etc/httpd” on chaoshome2, and the “passwd” directory in “/fedora8/var/www/.htpasswds” to “/var/www/” on chaoshome2: [root@chaoshome2 username] # cp –ipR /fedora8/etc/httpd/passwd /etc/httpd/  For webdav directories [root@chaoshome2 username] # cp –ipR /fedora8/var/www/.htpasswds /var/www/  For dir pw protected with .htaccess file

Rather than make new certificate and key files I decided to copy the combined certificate and key file I just updated last month into the same directory: [username@chaoshome2 ~]$ sudo cp -p /fedora8/etc/pki/tls/certs/host.domain.net.pem /etc/pki/tls/certs/

Note: Here’s where all of the source files for web pages (and wordpress blog pages) are copied.

Copied the root files for httpd server (/var/www/html) from Fedora 8 to Fedora 14: [username@chaoshome2 ~]$ sudo cp -ipR /fedora8/var/www/html/* /var/www/html/  This took several min.

Copy the webdav files over: [root@chaoshome2 username]# cp -ipR /fedora8/var/www/webdav /var/www/

Copy webalizer data:

First saved original directories: [root@chaoshome2 username]# cp -pR /var/www/usage /var/www/usage.orig [root@chaoshome2 username]# cp -pR /var/lib/webalizer /var/lib/webalizer.orig [root@chaoshome2 username]# cp -ipR /fedora8/var/www/usage/* /var/www/usage/  Copy data cp: overwrite `/var/www/usage/msfree.png'? n  Don’t overwrite files cp: overwrite `/var/www/usage/webalizer.png'? n [root@chaoshome2 username]# cp -ipR /fedora8/var/lib/webalizer/* /var/lib/webalizer/  Copy data

Restart httpd and make sure it is started at boot time. [root@chaoshome2 username]# chkconfig --level 35 httpd on [root@chaoshome2 username]# service httpd start Starting httpd: [ OK ] [root@chaoshome2 username]#

Check to see that crond is set to run webalizer daily Look in /etc/cron.daily: found 00webalizer script that calls webalizer.

Webalizer statistics on the web server traffic are found at: http://192.168.20.102/usage/

Finally, I set up the router to forward ports 443 and 80. So only three ports (22, 80, and 443) are forwarded into the local network domain. This provides about as secure a system as possible if I want to run a web server.

------

14. Install php and mysql packages in preparation for migrating wordpress:

I used “rpm –qa | grep php” and “rpm –qa | grep -i mysql” on both Fedora 8 and Fedora 14 system and compared the results to find out whether I needed to install any additional packages. I found that all the essential packages are already installed on the Fedora 14 system. However, I decided to install a few additional packages: [root@chaoshome2 username]# yum install php-gd php-pgsql phpMyAdmin php-xml [root@chaoshome2 username]# yum install proftpd-mysql

Find what directories php uses: ]# whereis php php: /usr/bin/php /etc/php.d /etc/php.ini /usr/lib/php /usr/share/php /usr/share/man/man1/php.1.gz

PHP is a hypertext preprocessor and is not a service and does not run as a daemon. We have already enabled httpd to use php to interpret php scripts, but since we have installed some new php packages we should reload the httpd: [root@chaoshome2 username]# service httpd reload Reloading httpd:

Now we can test to see that our httpd is able to display php script. Make a simple file called "hi.php": ]# echo "" > /var/www/html/hi.php

Point browser to: http://192.168.20.102/hi.php and should get a very simple "Hello, world."... web page. It works! Also, made another simple file to display php info: ]# echo "" > /var/www/html/php_info.php

Point browser to: http://192.168.20.102/php_info.php Get nice pages of information about the installed PHP version 5.2.5. PHP appears ready.

Now must finish readying mysql and phpMyAdmin. Find out where mysql files are located: ]# whereis mysqld mysql: /usr/bin/mysql /usr/lib/mysql /usr/share/mysql /usr/share/man/man1/mysql.1.gz

MySQL does run as a daemon. So must set the F8 system to start mysqld at boot time (and start the daemon now since we do not want to reboot right now.) I could use the GUI System -> Administration -> Services program to do this but I decided to use the command line commands "chkconfig" and "services": [root@chaoshome2 username]# chkconfig --list mysqld mysqld 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@chaoshome2 username]# chkconfig --level 35 mysqld on [root@chaoshome2 username]# chkconfig --list mysqld mysqld 0:off 1:off 2:off 3:on 4:off 5:on 6:off [root@chaoshome2 username]# service mysqld status mysqld is stopped

[root@chaoshome2 username]# service mysqld start Initializing MySQL database: Installing MySQL system tables... OK Filling help tables... OK To start mysqld at boot time you have to copy support-files/mysql.server to the right place for your system PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: /usr/bin/mysqladmin -u root password 'new-password' /usr/bin/mysqladmin -u root -h chaoshome2.localdomain password 'new-password' Alternatively you can run: /usr/bin/mysql_secure_installation which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the manual for more instructions. You can start the MySQL daemon with: cd /usr ; /usr/bin/mysqld_safe & You can test the MySQL daemon with mysql-test-run.pl cd /usr/mysql-test ; perl mysql-test-run.pl Please report any problems with the /usr/bin/mysqlbug script! [ OK ] Starting mysqld: [ OK ] [root@chaoshome2 username]#

Now need to set the root password for the mysql database as suggested above. [root@chaoshome2 username]# mysqladmin -u root password ********** [root@chaoshome2 username]# mysqladmin -u root -h chaoshome2.localdomain password **********

Test by opening the mysql database: [root@chaoshome2 username]# mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 5 Server version: 5.1.52 Source distribution

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> exit Bye [root@chaoshome2 username]#

Now, the system seems to be ready for wordpress

------

15. Migrate my Wordpress blog database from Fedora 8 to Fedora 14 system:

Note: I had already copied the wordpress source files as described in section

The plan here is “simple”: a. Define a new user, user-password, database, hostname in MySQL These four things must be exactly the same as were used when defining each blog’s database in Wordpress. This information resides in the wordpress file: "wp-config.php". b. Restore the entire wordpress databases from Fedora 8 mysql backups to the Fedora 14 mysql databases.

Note: I have two wordpress blogs: blog (Chaosworld) with database: wordpress mysql user username fampics (Familypics) with database: wppics mysql user username

Step a: I could have used the GUI: phpMyAdmin system installed earlier but I used sql to do it directly in mysql.

Look at the wordpress configuration file to double check on the four quantities:

]# cat /var/www/html/blog/wp-config.php

Now create this database and user in MySQL:

[root@chaoshome2 username]# mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 29 Server version: 5.1.52 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> CREATE DATABASE wordpress; Query OK, 1 row affected (0.00 sec) mysql> GRANT ALL PRIVILEGES ON wordpress.* TO "username"@"localhost" -> IDENTIFIED BY "******"; Query OK, 0 rows affected (0.00 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec) mysql> EXIT; Bye [root@chaoshome2 username]#

This created both the database “wordpress” and the mysql user “username”.

Did exactly the same to create the “wppics” database and again associated it with “username”.

Step b:

Save the mysql databases from Fedora 8 system and restore them to Fedora 14 system.

I routinely save the databases whenever I update wordpress. I have a script called “wpbkupall” that does using the mysql command: “mysqldump --add-drop-table -h localhost -u username -p wordpress > wordpress-wpx.x.x.bak.sql The files “XYZ.bak.sql” are snapshots of the entire database and can be used to restore the database.

In order to restore the database with these complete dumps is (as I understand it) to start with a clean (empty) database owned by the correct user. That is just the condition we have. I just created the databases.

I used my script to produce complete copies of the two databases in files: wwpics-wp3.0.4.bak.sql and wordpress-wp.3.0.4.bak.sql

Then restored each database with the following:

]# mysql -h localhost -u username -p wppics < /home/username/wp-data-bkup/wppics-wp3.0.4.bak.sql Enter password: ]# mysql -h localhost -u username -p wordpress < /home/username/wp-data-bkup/wordpress-wp3.0.4.bak.sql Enter password: [root@chaoshome2 username]#

Now test by pointing browser to the blog: http://192.168.20.102/blog/ and http://chaoshome2/fampics/ Get BLANK pages! Same thing for both blogs. Same thing when go to …/blog/wp-admin Hopefully this is a simple problem. There were no database errors reported. Checked httpd error log: “/var/log/httpd/error_log:

[root@chaoshome2 httpd]# tail error_log [Sun Feb 13 11:42:38 2011] [error] [client 184.57.81.239] PHP Parse error: syntax error, unexpected $end in /var/www/html/chaosworld/wp-content/plugins/comment_quicktags_plus.php on line 189

There must have been a change in php from the version that is on Fedora 8 to the one now on Fedora 14. Went into the wordpress files “blog/wp-content/plugins” and removed the “comment_quicktags_plus” plugin. Retested by pointing browser to the blogs as before.

Both blogs work! Time for a drink!

But before the drink I remembered that my “wpbkupall” script also saves a RAW copy of the mysql (wordpress) databases in the directory “/var/lib/mysql/bkup/”. So I copied that directory from chaoshome to chaoshome2: [root@chaoshome2 username]# cp –ipR /fedora8/var/lib/mysql/bkup /var/lib/mysql/

UPDATE: 3 Mar 2012: A weekly backup job is now in the root crontab that places a weekly copy of the MySQL databases for each of the blogs. That copy is stored in /root/wpdb. Only one copy is saved, i.e., it is overwritten each week, but the weekly and monthly system backups mean I have monthly copies saved both on the Fedora system and on a PC Hard Drive. ------

16. Installing/Migrating DAViCal to Fedora 14

I had successfully installed DaviCal on my Fedora 8 server using the following reference: (DaviCal:jms) http://www.jms1.net/davical/server-setup.shtml There is one important change in the order of one step in the above reference URL, so read through this full section before starting work.

Installing DAViCal can be divided into six steps: 1. Acquire and install the required packages. 2. Configure the postgresql server, initialize the psql database, and start the server. 3. Create the davical database within psql 4. Configure httpd for davical 5. Configure DAViCal itself. 6. Finishing the setup of the CalDAV server. (Logging as admin, changing admin password, creating CalDAV users.)

16.1. Get and Install the required packages:

I only needed one package on the yum-list provided in the above reference DaviCal:jms [username@chaoshome2 ~]$ sudo yum install perl-YAML

Installing the libawl-php and davical packages:

I found out where to get the two packages from http://wiki.davical.org/w/Downloading and downloaded the most recent versions of each using Firefox. davical-0.9.9.4-2.noarch.rpm libawl-php-0.46-2.noarch.rpm

I also downloaded the doc files for both packages. Changed to the directory containing the rpm files and:

[username@chaoshome2 DAViCal]$ sudo rpm -ivh davical-0.9.9.4* and [username@chaoshome2 DAViCal]$ sudo rpm -ivh libawl-php-0.46*

16.2. Configure the postgresql server, initialize the database, and start the postgresql server:

The postgresql does have a server, so we must start the server and make sure it will start at boot time.

[root@chaoshome2 username]# service postgresql status postmaster is stopped  the postgresql is not running [root@chaoshome2 username]# chkconfig --list postgresql postgresql 0:off 1:off 2:off 3:off 4:off 5:off 6:off  and is not set to be on at any run level [root@chaoshome2 username]# chkconfig --level 35 postgresql on  set on for run levels 3 and 5 [root@chaoshome2 username]# chkconfig --list postgresql postgresql 0:off 1:off 2:off 3:on 4:off 5:on 6:off  Check the run level setting [root@chaoshome2 username]# service postgresql start  Try to start postgresql server /var/lib/pgsql/data is missing. Use "service postgresql initdb" to initialize the cluster first. [FAILED]  Failed. Need to initialize db [root@chaoshome2 username]# service postgresql initdb < Initializing database: [ OK ]  Initialize [root@chaoshome2 username]# service postgresql start  Start server Starting postgresql service: [ OK ]

16.3. Create the davical database (following DaviCal:jms) [with one important change]:

I started here, but it fails. Must change a configuration file FIRST, then do this.

[root@chaoshome2 ~]# cd /usr/share/davical/dba [root@chaoshome2 dba]# su postgres -c ./create-database.sh

DBI connect('dbname=davical','davical_dba',...) failed: FATAL: Ident authentication failed for user "davical_dba" at ./update-davical-database line 244 Can't connect to database davical at ./update-davical-database line 244. * * * * ERROR * * * * The database administration utility failed. This may be due to database permissions for the davical_dba user, or because the Perl DBD::Pg or YAML libraries are not available.

Check that your pg_hba.conf allows the davical_dba user to connect to the database (and make sure you've reloaded PostgreSQL since changing that).

Also see: http://wiki.davical.org/w/Install_Errors/No_Perl_YAML

This also happened when I installed DAViCal on Fedora 8….some how I managed to succeed then but, of course, I have forgotten how I did it. The davical database was created the process was not completed. And, the script would not even attempt to complete the job when I tried the second time ---giving an error saying the davical database already exists! So to proceed I was going to have to start all over and reinstall the postgresql database server, or find out how to delete the existing, partially complete davical database.

Partly tested the postgresql database: URL ref: http://www.alphatek.info/2008/03/22/getting-postgresql-to-work-in-fedora/

[root@chaoshome2 dba]# su - postgres -bash-4.1$ createuser -P dbadmin Enter password for new role: Enter it again: Shall the new role be a superuser? (y/n) y -bash-4.1$ createdb -O dbadmin testdb -bash-4.1$ logout

The pgsql database itself seems OK.

After trying several things, I stumbled upon what to do to proceed past the above catastrophic failure and how to avoid it in the future! The following URL was helpful: http://ubuntuguide.org/wiki/DAViCal_current_version

I found out the following in the process:

1. When “postgresql” is installed a linux user “postgres” is created. The root user in pgsql is also “postgres”. 2. Important database data files are located at: /var/lib/pgsql/… including /var/lib/pgsql/data/pg_hba.conf 3. Important davical scripts and httpd pages are stored at /usr/share/davical/… 4. The root user in “pgsql” is “postgres” associated with (a minimal) database “postgress” 5. The user “postgres” uses the bash shell and can execute operations on the psql environment…such as create users and databases….with commands executed in the bash shell. 6. The script /usr/share/davical/create-database.sh (provided by the davical package) creates: psql user “davical_dba” as owner of the (also created) “davical” database, functions, tables, etc. psql user “davical_app” as the communicator between httpd and davical (I believe).

7. The following short session enters bash shell as root user “postgres” then enters the psql davical database; performs some queries on the (already existing) davical database and then exits. Then user davical_dba (owner of the davical database) does a login to the bash shel and then deletes the entire davical database from the psql system. Then an attempt is made to re- enter the psql davical environment (which fails) showing the davical database is gone. Finally, the session ends with an exit from the bash shell. [username@chaoshome2 dba]$ sudo su [root@chaoshome2 dba]# su postgres bash-4.1$ psql davical psql (8.4.7) Type "help" for help. davical=# \dt List of relations Schema | Name | Type | Owner ------+------+------+------public | access_ticket | table | postgres public | addressbook_address_adr | table | postgres public | addressbook_address_email | table | postgres public | addressbook_address_tel | table | postgres . . . davical-# \help Available help: ABORT CREATE LANGUAGE DROP TEXT SEARCH DICTIONARY ALTER AGGREGATE CREATE OPERATOR DROP TEXT SEARCH PARSER ALTER CONVERSION CREATE OPERATOR CLASS DROP TEXT SEARCH TEMPLATE ALTER DATABASE CREATE OPERATOR FAMILY DROP TRIGGER . . . davical-# \q bash-4.1$ login davical_dba bash-4.1$ dropdb davical  here is where the database is deleted bash-4.1$ psql davical psql: FATAL: database "davical" does not exist bash-4.1$ exit exit

There are several other useful commands that I stumbled upon. For example: \du lists users attributes, etc.

I had to discover how to delete the davical database because, after the above Failure it would not try again because the davical database already existed. Now that the davical database has been deleted we can start over.

The very important step that my top reference URL does not mention soon enough is that you must FIRST edit the “pg_hba.conf” file and insert the following lines at the top of its uncommented section: local all all trust local davical davical_dba trust local davical davical_app trust host davical davical_app 127.0.0.1/32 trust

After these four lines are added and the file is saved, I must restart the postgresql server so it will read the revised conf file. [root@chaoshome2 dba]# service postgresql restart Stopping postgresql service: [ OK ] Starting postgresql service: [ OK ]

Now, we are ready to retry to create the DAViCal database: [root@chaoshome2 data]# sudo su [root@chaoshome2 data]# su postgres -c /usr/share/davical/dba/create-database.sh Supported locales updated. Updated view: dav_principal.sql applied. CalDAV functions updated. RRULE functions updated. Database permissions updated. NOTE ==== * The password for the 'admin' user has been set to 'cmUvN90R'

Thanks for trying DAViCal! Check in /usr/share/doc/davical/examples/ for some configuration examples. For help, visit #davical on irc.oftc.net.

It is very important to write down the ‘admin’ user password given in the output above! I will need it later. My ‘admin’ password is: cmUvN90R This is a temporary password that will be used and changed.

Now I remove the line: local all all trust from the pg_hba.conf file using vi: ]# vi /var/lib/pgsql/data/pg_hba.conf

So far, so good.

16.4. Configuring httpd for DAViCal:

Actually, this was already done in section 13. But I checked it again. The following four lines must appear in “httpd.conf” somewhere. Order deny,allow Allow from all /davical

They are found at line 612 in the main configuration file “/etc/httpd/conf/httpd.conf”

The following line is near the bottom of the “/etc/httpd/conf.d/ssl.conf” file inside the . . Alias /caldav/ "/usr/share/davical/htdocs/" . .

[Note: since the port=443 and the name is _default_(=server-name), this Alias statement makes the URL to the CalDAV server: https://host.domain.net/caldav/ ]

After making changes to httpd.conf files we must restart the htppd: [root@chaoshome2 username]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ]

16.5. Configuring DAViCal itself:

I used vi to make a new file “/etc/davical/host.domain.net-conf.php [root@chaoshome2 username]# vi /etc/davical/host.domain.net-conf.php

To contain the lines: admin_email = '[email protected]' ; $c->system_name = 'SSL DAViCal CalDAV Server' ; $c->default_locale = 'en_US.UTF-8' ; $c->pg_connect[] = 'dbname=davical port=5432 user=davical_app' ; ?>

Set the permissions 644 (meaning rw-r--r-- access for owner-group-others) on the new configuration file: [root@chaoshome2 username]# cd /etc/davical [root@chaoshome2 davical]# chmod 644 host.domain.net-conf.php [root@chaoshome2 davical]# ll total 4 -rw-r--r--. 1 root root 233 Nov 28 00:44 host.domain.net-conf.php

If the davical-doc-x.x.x.rpm was installed, then some information on this “server-conf.php” file can be found at /usr/share/doc/davical/examples

16.6. Finishing the setup of the CalDAV server:

The URL (determined by the httpd configuration in section 16.4) is https://host.domain.net/caldav/ Note the trailing “/” is required. Point Browser to this URL and you will get a login prompt (if all goes well). (Of course, at this point I had to get into the router and change the port forwarding from chaoshome to chaoshome2 so I could use the real server name used in the setup here. I tried to access the CalDAV server using the local LAN address and it did bring up a page that let you know that it was almost working.)

The First Login must be username: admin password: ******** obtained in section 16.2 when the database was created. Logging in as “admin” gets you to the “home” screen containing links to all the information required for the complete administration of the CalDAV server. Changing the admin password (and even the admin username if so desired) should be done first. At the top of the home screen, mouse-over the “User Functions” tab and click on “View My Details” where the administrator can view or edit various properties. I left the name set to “admin” but changed the password and clicked on APPLY CHANGES at the bottom of the top-page.

You must login as administrator in order to create a new user with an initial password. Each user can login (with their initialpassword) and then change their password and manage their own CalDAV account information. A user can import an existing “anyname.ics” calendar file. The default URL for username’s CalDAV calendar: (URL placed in a calendar client for viewing and updating the calendar.) https://host.domain.net/caldav/caldav.php/username/home

A user can have more than one .ical calendar. A user can choose a directory name for each. For example username could have a additional calendars: calB.ics and CalC.ics. The user could give each one a folder. Put CalA.ics in “home”, CalB.ics in “calendarB” directory, and CalC.ics in “calendarC” directory. Then the URL for username’s CalB.ics calendar would be: https://host.domain.name/caldav/caldav.php/username/calendarB

Note: I found Mozilla’s Sunbird and the Lightning (addon for Thunderbird) work well with the DAViCal CalDAV server. Also, it works well with iPhone and iPod. ------

17. Setting up cron on Fedora 14 (to do the backup jobs etc.)

Once I changed the port forwarding (only three ports are forwarded: 22 for ssh, 80 for httpd, and 443 for https and ssl) I needed to transfer the backups dependently performed by Fedora 8 to the new Fedora 14. Just had to make sure the crontab files were in place and had the correct scripts.

The crontab files (or crontabs) are located in /etc. You can get a listing using “whereis cron” and a list of files and directories is provided. Interestingly, the list is missing the user crontab files found in “/var/spool/cron/”. The /etc/crontab file is a sort- of-template showing the format for the user crontab files. The directories cron.d, cron.hourly, cron.daily, cron.weekly, cron.monthly contain executable programs or scripts that are to be run at the corresponding period. I compared these directories between systems and attempted to make sure that the necessary programs were included in Fedora 14.

Each user can have their own crontab file that should be edited using the program “crontab”, actually the user executes: “crontab –e” to edit their own crontab file. I checked /var/spool/cron directory for user crontab file (which are simply files with name=username). I only have the root user with a crontab file. And it is the backup jobs that are listed in that file. I simply copied the old root crontab file over to the new Fedora 14 system: [root@chaoshome2 username]# cp –p /fedora8/var/spool/cron/root /var/spool/cron/

As root, I used “crontab –e” to see that it now had the correct scheduled processes.

UPDATE: 2 Mar 2012: Copied /var/spool/cron/root to /root/copyofrootcrontab just to have a copy for safe keeping.

Done. After a while, I can check the cron log at “/var/log/cron” to see what cron is doing: ]$ sudo more /var/log/cron ------18. Installing/Migrating ddclient to Fedora 14:

I used yum to install ddclient:

[root@chaoshome2 ~]# yum install ddclient

Found the configuration file at: /etc/ddclient.conf

Compared the new ddclient.conf with the old and edited the new file so it matched the old and then tested: [root@chaoshome2 etc]# ddclient -daemon=0 -debug -noquiet DEBUG: proxy = DEBUG: url = checkip.dyndns.org/ DEBUG: server = checkip.dyndns.org DEBUG: get_ip: using web, checkip.dyndns.org/ reports 184.57.81.239 DEBUG: DEBUG: nic_dyndns2_update ------DEBUG: proxy = DEBUG: url = http://members.dyndns.org/nic/update?system=dyndns&hostname=host.domain.net&myip=184.57.81.239 DEBUG: server = members.dyndns.org SUCCESS: updating host.domain.net: good: IP address set to 184.57.81.239

It worked so I setup the running of ddclient as a service that automatically starts at boot time:

[username@chaoshome2 ~]$ sudo service ddclient status ddclient is stopped [username@chaoshome2 ~]$ sudo chkconfig --list ddclient ddclient 0:off 1:off 2:off 3:off 4:off 5:off 6:off [username@chaoshome2 ~]$ sudo chkconfig --level 345 ddclient on [username@chaoshome2 ~]$ sudo chkconfig --list ddclient ddclient 0:off 1:off 2:off 3:on 4:on 5:on 6:off [username@chaoshome2 ~]$ sudo service ddclient start Starting ddclient: [ OK ]

Done. ------

19. Installing the Adobe Flash Player Plugin.

I followed MJMsIG for 32 bit Fedora 14 system: (enter all on one line) [username@chaoshome2 Download]$ sudo rpm -ivh http://linuxdownload.adobe.com/adobe- release/adobe-release-i386-1.0-1.noarch.rpm [username@chaoshome2 Download]$sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux Install the plugin: [username@chaoshome2 Download]$ sudo yum install flash-plugin

I tested by pointing Firefox to http://www.adobe.com/shockwave/welcome/ amd clicking on “Test Flash Player” and it did not work! I found the above produced the plugin file but did not place it in the correct directory for Firefox (seems to be /usr/lib/mozilla/plugins). I found the file produced was /usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.libflashplayer.so So I simply placed a soft link to that file as follows: $ cd /usr/lib/mozilla/plugins $ sudo ln –s /usr/lib/mozilla/plugins-wrapped/nswrapper_32_32.libflashplayer.so libflashplayer.so

Done. The Adobe test page says I have Flash Player for Linux Firefox version 10.2.152.27. ------20. Enabling Remote Login with vnc and gdm login screen

Used two reference URLs: http://codeghar.wordpress.com/2009/06/11/remote-login-with-gdm-and-vnc-on-fedora-11/ http://forums.fedoraforum.org/showthread.php?t=94257

Note there are at least two ways to set up a remote login: 1. Have vnc server running a user session in background all the time and then connect into that session from external computer. 2. No vnc session running perpetually, instead start a gdm login session from the external computer and then login as you would from the console.

I had the second type of remote VPN login from Windows to the local Fedora 8 computer from via an ssh tunnel setup on the Fedora 8 computer. I prefer this for a couple of reasons: a) There is no extra login session always running in the background on the Linux machine; and b) If method 1 is used, you must be careful not to logout when you end the remote session because if you log out, you end the vpn server session and you will not be able to login again until you restart the vpnserver or reboot the Linux machine.

On the-the-other-hand there are a couple of minor problems with method 2 as well, but they seem not to be serious.

So method 2: vnc with gdm remote login is described here.

20.0 Install required packages:

All the required packages (vnc-server and xinetd) were already installed (I ran (as root) “yum install vnc-server” and “yum install xinetd” and neither had anything to do).

20.1 Make sure the vncserver is NOT running initially and xinetd IS running initially:

Turn off the vncserver and on the xinetd: $ sudo service vncserver stop $ sudo service xinetd start

Make sure the vncserver is not started at boot time and that xinetd is: $ sudo chkconfig –level 123456 vncserver off $ sudo chkconfig –level 35 xinetd on

20.2 XDMCP (X Display Manager Control Protocol) setup for the GDM (Gnome Display Manager):

The gdm displays the login x-window and it must be set up to accept a remote request.

Edit “/etc/gdm/custom.conf” file: $ sudo vi /etc/gdm/custom.conf

Make sure the following lines are present in the sections indicated:

[xdncp] Enable=true

[security] AllowRoot=false DisallowTCP=false

20.3 Create the vnc display tcp services and corresponding xinetd tcp display services:

Create the vnc services by editing the “/etc/services” file: $ sudo vi /etc/services

Comment-out the following lines: #vnc-server 5900/tcp # VNC Server #vnc-server 5900/udp # VNC Server

Then at the bottom of the file I added the following two lines creating two local services -- vnc displays at ports 5904 & 5905 (ports 5900 – 5009 are conventionally reserved for vnc displays): vnc-wdx24 5904/tcp # vnc -- gdm login 1024x766x24 using xinetd for wide scr laptop vnc-lgx24 5905/tcp # vnc -- gdm login 1272x986x24 using xinetd for large scr desktop

Create the corresponding xinetd display services by creating two new files, “vnc-wdx24” and “vnc-lgx24”:

$ sudo vi /etc/xinetd.d/vnc-wdx24 Add the following lines: service vnc-wdx24 { disable = no socket-type = stream protocol = tcp group = tty wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -query localhost -geometry 1024x766 -depth 24 -once –fp /usr/share/X11/fonts/util -securitytypes=none }

$ sudo vi /etc/xinetd.d/vnc-lgx24 Add the same lines as above except change the geometry to “-geometry 1272x986”.

Now, restart xinetd: $ sudo service xinetd restart

Fedora 14 is now configured to allow external vnc display login.

I have the Tight-vnc client installed on my windows machine and use SecureCRT to tunnel through ssh (port 22) for a remote login session using port 5905 to get the large window (or port 5904 for the smaller window). It works, but there are a couple of “minor” problems:

Problem 1. An error box immediately comes up on a black screen with the configuration error: /usr/libexec/gconf-sanity- check-2 exited with status 256. If I close the error box, things proceed as if nothing was wrong. I searched the web to try to fix this problem but no luck yet. I did find others that had the same problem and they were still working around it by ignoring it (as am I). Problem 2. Before I can use any GUI program (even the email reading program will not get new mail) as root in the remote X-window, I must execute the following command in a terminal window (within the remote X-window): $ sudo xhost +localhost Problem 3. I could not use Copy and Paste (the clipboard) to transfer things from or to the remote window.

I declare this OK, for now, but there seem to be too many changes between Fedora 8 and 14 and this is not working well. ------21. Enable Remote Login using vnc alone.

As mentioned at the end of the last section, there are problems using gdm for remote login. After looking at the log files “/var/log/gdm/*”, I found there were many errors that I could not find out how to eliminate. So I decided to set up the other method (listed as method 1 at the beginning of the previous section) which allows login to a running vnc desktop process. Using this method, vncserver must start at boot time and continually run with vnc-desktop processes.

Reference URL: http://stevejenkins.com/blog/2010/11/how-to-set-up-vnc-from-windows-to-fedora-14-over-the-internet/

I followed the above reference closely. There are 10 steps to the process in the description. There are changes I needed to make that include a roll-back from part of what was done in the previous section.

Step 1: Make sure ssh is running. I did that back in section 8.

Step 2: Install TigerVNC-server. That was already done.

Step pre-3: Roll-back some things done in section 20:

In this arrangement, I will be running the vnc server all the time. This is just the opposite of what was set up in the previous section. Also, I no longer need xinetd to start the x-desktop at login time. Therefore I need to roll back some of what was done.

Stop the xinetd: [username@chaoshome2 ~]$ sudo service xinetd stop Stopping xinetd: [ OK ]

Configure to NOT start xinetd at boot time: [username@chaoshome2 ~]$ sudo chkconfig --level 123456 xinetd off

Configure to start vncserver at boot time: [username@chaoshome2 ~]$ sudo chkconfig --level 35 vncserver on [username@chaoshome2 ~]$ chkconfig --list vncserver vncserver 0:off 1:off 2:off 3:on 4:off 5:on 6:off

I need to take away the xinetd tcp display services that we setup in step 20.3 above. This means put the “/etc/services” file back as it was before section 20.

Edit /etc/services [username@chaoshome2 ~]$ sudo vi /etc/services

Comment out the following lines: #vnc-wdx24 5904/tcp # vnc -- gdm login 1024x766x24 using xinetd for wide scr laptop #vnc-lgx24 5905/tcp # vnc -- gdm login 1272x986x24 using xinetd for large scr desktop

Un-comment the following lines: vnc-server 5900/tcp # VNC Server vnc-server 5900/udp # VNC Server

Now I am ready to configure the new vnc desktops.

Step 3: Configure screen resolutins, Port numbers and Users that are allowed to login remotely on the Fedora 14 computer.

The “/etc/sysconfig/vncservers” file controls what users can perform a remote vnc login and the geometry of the vnc desktop.

Edit the file: [username@chaoshome2 ~]$ sudo vi /etc/sysconfig/vncservers

And add the lines below: VNCSERVERS="1:renoteusername 2:remoteusername" VNCSERVERARGS[1]="-geometry 1020x760 -nolisten tcp -localhost" VNCSERVERARGS[2]="-geometry 1272x986 -nolisten tcp -localhost"

The above lines creates two vnc desktops associated with user remoteusername. Of course remoteusername must have an account on the Fedora 14 computer. The first is screen :1 (using port 5901) and the second screen :2 (using port 5902). The geometry of the screens are also set in this file.

Note: I used ports 5901 and 5902 because they had not been used yet. I used ports 5904 and 5905 in the previous section and by not reusing those I can switch back and forth between the two methods rather easily, if desired.

Step 4: Configure Desktop Environment and user VNC Password

The - is important because it will load into the shell the local path for user “username”. The user password is required. Now type: [remoteusername@chaoshome2 ~]$ vncserver

This runs the vncserver program and when run for the first time it will set up the default version of the users’s desktop configuration files in a hidden folder .vnc I was asked for a password for remoteusername. This password will be required when the user logs in remotely to the vnc desktop. The vnc password can (and should be (for more security)) be different than the user remoteusername’s password to their computer account. If the user wants to change their vnc password they can login locally and issue the command: “vncpasswd”. To login from outside the local network, the user remoteusername would first ssh into the computer (requiring their account password) and then the system would tunnel through to port 5901 (to use vnc-desktop :1) or port 5902 (to use vnc-desktop :2) and they would be asked for the vnc password.

The vncserver command also created an xstartup file in the .vnc directory (/home/remoteusername/.vnc/xstartup). I need to edit this file: [remoteusername@chaoshome2 ~]$ sudo vi /home/remoteusername/.vnc/xstartup

Modify the bottom of this file by commenting out “twn &” and adding a line telling VNC to start the x-desktop. # twb & startx &

Save the “/home/remoteusername/.vnc/xstartup” file.

Type “exit” twice to return to the original user.

Step 5: Start the vnc-server service

Make sure any previous instance of the vncserver is not running: [username@chaoshome2 ~]$ sudo service vncserver stop

Start the vnc-server service (which will create the two vnc-desktops as background processes [username@chaoshome2 ~]$ sudo service vncserver start Starting VNC server: 1:remoteusername 2:remoteusername [ OK ]

Step 6: Set SELinux to allow port forwarding.

Although I have SELinux set to “permissive” (I may disable it soon), I have been attempting to keep it satisfied. Apparently this requires setting a Boolean to allow port-forwarding: ]$ sudo # setsebool -P sshd_forward_ports 1

Step 7: Set up the Firewall to let vnc ports receive incoming connections

Note: I did not think this was necessary, and things seemed to work without setting up the Firewall. But there were many lines in the log files (/home/username/.vnc/chaoshome2.localdomain:1.log and ….:2.log) and these files got much “more quiet” after setting up the firewall as described below.

Edit “/etc/sysconfig/iptables” ]$ sudo vi /etc/sysconfig/iptables

Add the following lines: -A INPUT -m state --state NEW -m tcp -p tcp --dport 5901 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 5902 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 5903 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 5904 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 5905 -j ACCEPT

I included all the ports I have considered using for vnc desktops. Save the modified file.

Copy and save the revised iptables file (just in case it is modified by deleting all direct edits as will happen if you inadvertently use the GUI Firewall application). ]$ sudo cp –p /etc/sysconfig/iptables /etc/sysconfig/iptables.RWR

Restart the firewall using the new iptables: ]$ sudo service iptables stop ]$ sudo service iptables start

Step 8: Test the new setup.

Use SecureCRT from Windows machine with tightVNC to use ssh and tunnel to port 5901 or 5902 to test: It works.

Somewhat strange behavior noted: 1. Do NOT logout at the end of your remote session. If you do you will be logging out of the vnc-desktop process and I could find no way to get logged back in, short of restarting the vncserver. Simply disconnect or kill the Window. Remember to close all running processes because they will continue running until you remote login again and stop them. The good side of this is that you can logout and then login again and find all windows and processes as the were at logout. 2. The copy and past does work to transfer via the clipboard form the vnc-desktop window to another window on the remote windows computer. You will notice a [VNC config] process icon on the bottom taskbar. If you open the window for that process and then kill it (by clicking on the x in the upper right corner) you will kill the clipboard transfer capability. Again (as in case 1 above) the only way to get this capability back is to restart the vncserver.

This arrangement seems to be somewhat better than the gdm login method.

------

22. Install Sunbird Calendar as a CalDAV client on Fedora 14

Used yum: $ yum install sunbird

The Mozilla Sunbird calendar program is found under: Applications > Office > Sunbird

------

23. Install Java runtime and Adobe reader following

ref. MJMsIG, above. ------

24. Trouble after an update using yum

On 13 Sept. 2011 I did a standard update of the Fedora 14 system using the usual yum command: # yum update

I rebooted the machine because a new kernel was installed (2.6.35.14-96.fc14.i686) and the machine failed to boot up. The screen showed the error:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

I tried shutting the machine off and back on to interrupt the grub boot menu and choose a previous kernel. Only one other kernel was shown (2.6.35.14-95.fc14.i686) and that kernel would not boot either – giving other errors and finally failing giving the same Kernel panic error listed above.

[As a temporary fix, I fired up the old chaoshome machine and updated the old system using the last weekly backup which the cron daemon had been dutifully copying over (along with the monthly backups) to my Desktop PC. The only things that needed updated were my iCAL calendar and the Wordpress blogs. The most recent iCAL file was available from the cron job which executes every three hours which exporting from DAViCAL postgresql database the iCAL calendar file to a …/calendars directory in my home directory. So I could login to DAViCAL and import the most recent iCAL file into position. The wordpress updates were also straight forward. Firstly, Wordpress itself was updated to the most current version and then the mysql database backup file was used to move the current data into place. That all went fine and in a few hours everything was working and up-to-date woth the server running under the old Fedora 8 system.]

With the server running acceptably on the old Fedora 8 system, I googled the error above and found that this is an apparently long standing Fedora-update bug! That is good in a way, because it was easy to find the solution. I did the following:

1) Boot the Fedora 14 machine from my Fedora 14 i386 Installation DVD and chose Rescue from the boot menu. 2) Choose the options that let it mount the old file system on /mnt/sysimage. 3) Choose the option that starts a terminal session. 4) Go to the grub boot directory at /mnt/sysimage/boot/grub and use vi to edit grub.conf so I could see the menu i.e. comment out the line “hiddenmenu” : #hiddenmenu (I already had the line timeout=10) 5) Reboot from the hard disk and choose the third kernel (2.6.35.14-92.fc14.i686 in this case) 6) This worked after some time-consuming SELinux relabeling 7) Go to /etc/grub.conf to delete the lines that refer to the bad kernel installation (Kernel 2.6.35.14-96.fc14.i686) 8) Go to /boot and delete the files that go with the 2.6.35.14-96.fc14.i686 kernel. This effectively removes the bad kernel. 9) Finally, to try to make sure I have a working kernel available, following this link I increased the number of Kernels saved by “yum update” by editing /etc/yum.conf and increasing the number on the “installonly_limit” line from 3 to 6. 10) Reboot.

These steps did the trick. All is back to normal. I ran “yum update” again and some new updates were found but, the offending kernel 2.6.35.14-96.fc14.i686 was not among the updates found. Perhaps, since I manually deleted that Kernel from the /boot directory rather than using yum uninstall to remove the Kernel, yum does not realize the new Kernel is not installed.

Note in the above that the final reboot used the 2.6.35.14-95.fc14.i686 kernel (and not the …-92.fc14.i686 kernel). I do not really know why the …-95.fc14.i686 kernel now works when it did not when I tried it right after the failed boot but somehow, booting from the DVD must have been responsible. So anyway, now the system is only one Kernel update away from completely up-to-date.

It will be interesting to see what happens when I use “yum update” to get the next new Kernel.

Note added 11 Jan 2012: subsequent update to next new Kernel went without a problem.

------

25. Upgraded DAViCal Server Sat. Feb. 25, 2012 . Ref. for DAViCal Server project: http://wiki.davical.org/w/Main_Page Note: DAV stands for Distributed Authoring and Versioning

Curently we are running the 0.9.9.4-2 version of the DAViCal Server and the current version is 1.0.2-1.

The DAViCal Wiki provides RPM packages (for RedHat Linux): RPM packages. I downloaded into the DAViCal directory (in my home directory) the following. awl-doc-0.51-1.noarch.rpm libawl-php-0.51-1.noarch.rpm davical-doc-1.0.2-1.noarch.rpm davical-1.0.2-1.noarch.rpm

Installed them all using the –U (upgrade) option on rpm:

]$ sudo rpm –Uvh awl-doc-0.51-1.noarch.rpm …… for each of the above rpm packages.

Enter the administration GUI front page by pointing a Browser to https://host.domain.net/caldav/. There was a message on the admin GUI front page telling me that the database must be updated. The “update-davical-database” script is part of the DAViCal package. I found (using the DAViCal Wiki information on Upgrading) how to do this. I simply issued the command:

]$ /usr/share/davical/dba/update-davical-database --dbuser=davical_dba The database is version 8.4 currently at revision 1.2.9. Applying patch 1.2.10.sql ... succeeded. Applying patch 1.2.11.sql ... succeeded. Successfully applied 2 patches. Supported locales updated. Updated view: dav_principal.sql applied. CalDAV functions updated. RRULE functions updated. Database permissions updated. ]$

Checked to see that Thunderbird/Lightning could still see and change my calendars. – all works just fine. Very easy upgrade! But not so fast…read on for some configuration changes to get things working smoothly.

Digression:

First a Digression on getting rid of some errors that were filling the /var/log/httpd/ssl_error_log. The following has nothing to do with the upgrade, except that the existence of DAViCal server lines in the /var/log/ssl_error_log file is the reason I decided to upgrade. Before upgrade, I found many lines (about 27 lines) appeared every time I restarted Thunderbird with the calendar showing.. Each line in the ssl_error_log file was a long warning:

PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead in /usr/share/davical/htdocs/always.php on line 65

After the successful upgrade, I rechecked the ssl_error_log file again. DAViCal was still producing multiple warnings. After some searching the web… I got rid of those warning lines by: un-commenting a line in the /etc/php.ini file: date.timezone=”America/New_York”

That fixed that warning “problem”.

One new error line now appears each time a DAViCal calendar is read: davical: LOG: request: Request specified content type but none is present. Assuming null content-type.

I don’t know what causes this, but it is only one line per calendar (the other error was several lines per calendar…and every time a calendar was read. So the situation now is much better than it was…but still not perfect.

End of Digression.

There were some changes in defaults that required some changes in the configuration file: /etc/davical/host.domain.net-config.php

The default home calendar was at davicaluser/home. Now it is davicaluser/calendar So I avoided having to change the server and calendar name on all clients by adding the line: $c->home_calendar_name = ‘home’ ; To make a long story short, I also added a line setting the parameter: “readonly_webdav_collections” so the full configuration file now is:

admin_email = '[email protected]' ; $c->system_name = 'SSL DAViCal CalDAV Server' ; $c->default_locale = 'en_US.UTF-8' ; $c->pg_connect[] = 'dbname=davical port=5432 user=davical_app' ; $c->home_calendar_name = 'home'; //the new default is 'calendar' $c->readonly_webdav_collections = false; //allows curl action PUT work command line loading of .ics files ?>

One additional quirk in the admin GUI was the option “Upload From File” is not clickable until you click "Is a Calendar" on and then off again on that GUI page. That maneuver fixes some bug in the javascript behind entering the location of an calendar.ics file that you want to upload to replace the current calendar. I also found that the “append” check box does nothing.

In the process of doing all this, I became familiar with the SourceForge.net Davical-general discussion group on the DAViCal CalDAV Server ran by Andrew McMillan. https://lists.sourceforge.net/lists/listinfo/davical-general

I also learned why the Mozilla Developers refuse to let Thunderbird/Lightning remember more than one DAViCal server’s calendaruser – password pair at a time. (I mean, in order to install and view a second calendaruser—password pair you must DELETE the previous calendaruser’s calendars entirely from Lightning.) I followed the discussion on the Mozilla Forums about this with a large group of users (me included) saying this was a bug in Lightning and others saying it was not a bug. Those who said it was not a bug said the “bug people” were people wanting to use bad CalDAV usage practices. I now understand what they mean. You are supposed to log on to a DAViCal CalDAV server with only one username—password, and you get access to other user’s calendars through permissions set by those users through administration on the DAViCal server . Each user (or Principal as they are called) can give permissions at various levels to other Principals with Collections (of events) [which the uninitiated would cal “calendars”] on the DAViCal server. Each Principal can have several Collections (or calendars) and each Collection has its own subdirectory. In our setup, the URL of the Principal with username A is: https://host.domain.net/caldav/caldav.php/A and A’s home collection (home calendar A1.ics) has URL: https://host.domain.net/caldav/caldav.php/A/home. If calendar user A had another Collection (second calendar A2.ics), its URL could be: https://host.domain.net/caldav/caldav.php/A/A2. Suppose Principal A has Collections (calendars) A1 and A2, and Principal B has Collections B1 and B2. Let’s say Principals A and B want to share collections A1 and B1 in Read/Write mode and only share A2 and B2 in Read. Each Principal can Grant two types of privileges to other Principals: Principal to Principal; and Collection to Principal. I found (by trial and error) that the way to set up the above sharing arrangement is to Grant the following: Principal A Grants Principal Read privileges to Principal B and Grants Collection A1 R/W privileges to Principal B and Grants Collection A2 R privileges to to Principal . Principal B Grants the corresponding privileges (Principal and Collection privileges) to Principal A. It sounds complicated, but it works. It can get even more complicated because a Principal may be a Resource (like a Room, say) or a Group (of Principals). I am stopping right there.

I also found two very useful commands (which must be executed as root):

The first command is to get a CalDAV calendar from the DAViCal Server to a text/calendar (name.ics) file format:

/usr/bin/wget --user=A --password=Apw --no-check-certificate --O out.ics https://host.dmn.net/caldav/caldav.php/A/home <

Gets user A’s /home/ calendar and copies it into a text/calendar file, out.ics.

Similarly the following command uploads the in.ics text/calendar file into (overwriting) user A’s /home/ CalDAV calendar: curl --insecure --basic --request PUT --header "Content-Type: text/calendar; charset=utf-8" –user A:Apw --data-binary @in.ips https://host.domain.net/caldav/caldav.php <

Backup of the DAViCal CalDAV system:

I have two backup methods.

Backup method 1: A daily cron job is run by root’s crontab using the wget command listed above to save copies each day of each collection on the Davical server. They are saved in a user’s directory on the Fedora system.

Backup method 2: A weekly cron job is run by postgres’ crontab. “postgres” is the superuser of the postgresql database. “postgres” has a home directory at /var/lib/pgsq. A copy of the davical database is saved in the directory /var/lib/pgsql/bkups weekly.

Both methods simply overwrite the previously saved copies. But, the above backup methods, together with the Monthly and Weekly system backup jobs result in monthly copies of the database and *.ics text/calendar files being saved to my local PC as well as on the Linux system.

------