Building a YUM repo
Yum is the application installer used by RedHat. It connects to various known repos to download requested software. To create a YUM repo simply drop all your rpm files into a directory on a web server and inform the RedHat system you wish to install them on by creating a file in /etc/yum.repos.d
The file should be called something.repo and the format follows the following:
name=My YUM repo baseurl=http://10.0.0.1/redhat5/myrpms/ enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
The gpgkey entry details a file with gpg auth details for the rpms in the repo, however, this will be disabled if gpgcheck is set to '0'.
SNAT – making IPs local
SNAT (Sender Network Address Translation) under IPtables on Linux. It's used where you need to change the IP address that the packet is seemingly coming from. Great for when you need to make traffic look local.
Picture a scenario where a company has two separate connections to the Internet (possibly via different suppliers):

A network using SNAT
Web traffic can happily arrive and exit via Router A as this is the default gateway for the Web Server. However rather than having two web servers with the same content, the intention is to have web traffic from Router B forwarded to the Web Server. The issue becomes the source IP address. The Web Server will happily accept the packets of data, but will then pass replies out via it's default gateway, namely Router A. Responses will never succeed and the connection will seemingly fail.
Cue SNAT!
It's possible to use SNAT to alter the source IP of the packet - in this case making the packet seemingly come from the Forwarder box. The Web Server will subsequently deem the packet as local and pass it back via it's local routes rather than it's default gateway. The Forwarder will then accept the packet and route it to the original IP that made the request via Router B.
In the above example, the forwarding and SNAT iptables rules for the Forwarder box would be as follows:
$ iptables -t nat -A PREROUTING -p tcp -d 9.8.7.7 --dport 80 -j DNAT --to-destination 10.0.0.1 $ iptables -t nat -A POSTROUTING -p tcp -o eth1 -j SNAT --to-source 10.0.0.2
Notice that the second ethernet card (eth1) was specified in the SNAT rule, and not an IP address, to ensure that ALL packets exiting this card are affected; this is because all traffic in the above example exiting eth1 is considered local traffic. However, it is possible to restrict exactly which IPs the rule should apply to if necessary.
Debian cups-pdf
The Common UNIX Printing System (CUPS) has long been the standard of printing and print drivers for Linux. Having a PDF printer can be extremely useful - so here's how to set one up in Debian.
First, you have to install the CUPS PDF print driver
$ aptitude install cups-pdf
Next, we need to actually configure the printer itself for use. In CUPS this can be easily done via a URL and a browser of your choice (even a text based browser). Simply head over to http://localhost:631/ and in the following screen select the "Administration" option

CUPS default screen
Then select to "Add Printer"

CUPS printer administration
How you configure the printer name and details is up to you and your setup, but it is easiest to simply use "PDF" as the printer name

CUPS add printer
Next select the "Virtual PDF Printer" as the device

CUPS select device
For the make and manufacturer of printer select Generic

CUPS make and manufacturer
Finally, for the model select the "Generic CUPS-PDF Printer(en)" option

CUPS model
At this point you will now have a PDF printer. Some customisation is possible in the file /etc/cups/cups-pdf.conf - for example, the default location for creating PDF files is in a PDF directory in the user's home directory as identified by this entry:
Out ${HOME}/PDF
Clearly you can adjust this to suit your needs. To demonstrate the post processing options available, uncomment the PostProcessing option and alter to read as follows
PostProcessing /usr/local/bin/cups-pdf-renamer
Edit the file /usr/local/bin/cups-pdf-renamer to look as follows:
1 2 3 4 5 6 7 | #!/bin/bash FILENAME=`basename $1` DIRNAME=`dirname $1` DATE=`date +”%Y-%m-%d_%H:%M:%S”` mv $1 $DIRNAME”/”$DATE”.pdf” |
Make sure the file is executable
$ chmod +x /usr/local/bin/cups-pdf-renamer
Essentially this will rename the file to a date and time stamp. Clearly you can alter this to suit your needs. This example was taken from here
Anonymous Windows PDF generation via SAMBA
On Ubuntu I'm completely used to the idea of printing out a PDF document of what I want/need. It saves on paper and allows me to keep digital copies; it can also prove indispensable if I need to send a copy via email.
At work, on Microsoft Windows, I have struggled with trying to do this. The only products available for PDF generation appear to be commercial. Through some tinkering with a Ubuntu server in the office I setup a PDF printer for all to use anonymously. Here's how...
Configuring Samba and PDF
The important thing to remember is that PDF printer on the server produces PDF files locally, and therefore access to the produced PDFs must be via SAMBA too.
Samba is usually installed by default, but if not, run:
$ sudo apt-get install samba
Changes need to be made to the config file /etc/samba/smb.conf to allow printing. Uncomment/add the following entries:
printing = cups printcap name = cups
We now need a location that anybody can read or write to (which is where our PDFs will be placed for pickup). In this example I will use the /tmp directory. To do this we add the following entry to the samba config file:
[tmp] comment = Samba server's tmp directory locking = no path = /tmp guest ok = yes create mask = 0666 read only = no
Restart Samba
$ sudo /etc/init.d/samba restart
You may already have the PDF printer installed (as cups is installed by default) however, if you don't, simply run:
$ sudo apt-get install cups-pdf
We now need to tell the cups-pdf printer where to otput its files. System users have their files printed to the folder ~/PDF. This has implications for samba users too. If you mount samba shares as a system user on the server then your PDFs will be printed to that user's ~/PDF directory. This may be what you want.
The file we need to alter is /etc/cups/cups-pdf.conf, specifically the following two entries:
Out ${HOME}/PDF
The above entry details where PDFs are created for system users. Altering this affects all system users AND samba users who use system user credentials to mount drives. Change this to suit your needs. Next is the AnonDirName entry, change it to:
AnonDirName /tmp
Now any anonymous user will have their PDFs placed in /tmp to pickup via samba. Restart CUPS - on Hardy (and earlier?) this appears to be:
$ sudo /etc/init.d/cupsys restart
but on Jaunty (and later?) it may be:
$ sudo /etc/init.d/cups restart
Configuring Windows
The example here has been completed on a Windows Vista machine, but should be similar for other versions. First you need to browse to the computer:

Windows printers
and double-click the "PDF" printer, which will start to install the printer. A printer driver error message will be displayed indicating that the printer driver could not be found:

Windows printer driver error message
This is not a problem. Simply click "Ok" to continue the install. You will now need to select a printer driver to use with the printer. The printer works with PostScript documents so I selected a HP PostScript printer driver to use with it, the 'HP LaserJet Series 1200 PS' - CafeNinja tested with the 'IBM 4079 Color Jetprinter PS' driver and achieved successful results

Windows add printer wizard
Once the driver has been installed the printer's queue will be displayed. Don't worry about the "Access denied, unable to connect" message - this has never stopped it working for me:

Windows printer queue
From the printer queue window select Printer > Properties to get to the properties window. Then select to "Print Test Page" - closing any "sent test page" window box that may appear

Windows printer properties
Now browse to the /tmp directory and collect the Windows (recognisable) printed PDF. Take note that the output PDF is in color too!

Windows test page PDF
Caveats
A couple of things to remember...
- The PDF gets its name from the file that was being printed - this could lead to accidental overwrites
- The files do not get auto-deleted so you may wish to setup a cron job to do this periodically
Concatinating PDF files
Sometimes there is a need to amalgamate many PDFs into a single PDF. Ghostscript is fully capable of achieving this and is usually available by default.
To concatenate any number of PDFs, cd to the appropriate directory containing the PDF files and issue the following command:
$ gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=finished.pdf -dBATCH *.pdf
Note that they are added to the finalised PDF in the order given - so "*.pdf" may not result in the order you would like, in which case you will need to manually specify each file in the desired order.
A quick breakdown to the options:
-dBATCH : Exit once Ghostscript processes the PDF files, otherwise Ghostscript will keep running
-dNOPAUSE : tells Ghostscript to process each page without pausing for user interaction
-sDEVICE=pdfwrite : tells Ghostscript to use its built-in PDF writer to process the files
-sOutputFile=finished.pdf : tells Ghostscript to save the output to the named file, in this case "finished.pdf"
Additional options you may want:
-sPAPERSIZE=letter : sets the paper size to American sized "letter"
-q : "quiet" mode, stops Ghostscript displaying messages while it works
Bridged VPN with OpenVPN
This VPN guide will use a bridged method (bridging the LAN connections to those of the Internet on a tap virtual interface.) This requires the bridge-utils to be installed - the OpenVPN software can be installed at the same time:
$ sudo apt-get install openvpn bridge-utils
Configure Networking
Typically, the VPN is on the LAN and the firewall transparently forwards packets from the outside world; this is the premise I will work from. The bridge will require the interfaces it manages to be in promiscuous mode, therefore, a typical bridge configuration on a Linux system could look as follows (where eth0 is managaed by the bridge br0) in /etc/network/interfaces:
## Start these interfaces on boot auto lo br0 iface lo inet loopback iface br0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 bridge_ports eth0 iface eth0 inet manual up ifconfig $IFACE 0.0.0.0 up up ip link set $IFACE promisc on down ip link set $IFACE promisc off down ifconfig $IFACE down
As seen above, we will assume a 192.168.1/24 private network. To have the changes take effect, the network needs to be restarted:
$ /etc/init.d/networking restart
As stated, OpenVPN will manage devices in promiscuous mode. When started, OpenVPN will create the tap device - however, the device needs to be added to the bridge we have created. To achieve this we will create two scripts which will be run by OpenVPN. The first, /etc/openvpn/up.sh will manage the addition:
#!/bin/sh BR=$1 DEV=$2 MTU=$3 /sbin/ifconfig $DEV mtu $MTU promisc up /usr/sbin/brctl addif $BR $DEV
The next, /etc/openvpn/down.sh will manage the removal of the tap device:
#!/bin/sh BR=$1 DEV=$2 /usr/sbin/brctl delif $BR $DEV /sbin/ifconfig $DEV down
We will see later how they are called. Finally, we make them executable:
$ chmod +x /etc/openvpn/up.sh /etc/openvpn/down.sh
Configure OpenVPN Server
We must generate certificates for the server. In order to do this we will setup our own Certificate Authority using the provided easy-rsa scripts in the /usr/share/doc/openvpn/examples/easy-rsa/ directory:
$ sudo mkdir /etc/openvpn/easy-rsa/ $ cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/
Before generating the CA we need to edit a file - /etc/openvpn/easy-rsa/vars. Change the values of the below entries to better reflect your CA:
export KEY_COUNTRY="US" export KEY_PROVINCE="CA" export KEY_CITY="SanFrancisco" export KEY_ORG="Fort-Funston" export KEY_EMAIL="me@myhost.mydomain"
Now we setup the CA and create the server certificate:
$ cd /etc/openvpn/easy-rsa/ ## move to the easy-rsa directory $ source ./vars ## execute your new vars file $ ./clean-all ## Setup the easy-rsa directory (Deletes all keys) $ ./build-dh ## takes a while consider backgrounding $ ./pkitool --initca ## creates ca cert and key $ ./pkitool --server server ## creates a server cert and key $ cd keys $ openvpn --genkey --secret ta.key ## Build a TLS key $ cp server.crt server.key ca.crt dh1024.pem ta.key /etc/openvpn/
By default all servers specified in *.conf files in /etc/openvpn/ are started on boot. Therefore, all we have to do is configure the openvpn server by creating /etc/openvpn/server.conf from the example file:
$ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/ $ gzip -d /etc/openvpn/server.conf.gz
Edit etc/openvpn/server.conf amending/setting the following options as required (note that we specify here how our networking up and down scripts are called and we have commented out the server line as we are using bridged mode):
local 192.168.1.10 dev tap0 up "/etc/openvpn/up.sh br0" down "/etc/openvpn/down.sh br0" ;server 10.8.0.0 255.255.255.0 server-bridge 192.168.1.10 255.255.255.0 192.168.1.100 192.168.1.150 push "route 192.168.1.0 255.255.255.0" push "dhcp-option DNS 192.168.1.1" push "dhcp-option DOMAIN example.com" tls-auth ta.key 0 # This file is secret user nobody group nogroup
- local: is the IP address of the bridge interface.
- server-bridge: is needed when the configuration uses bridging. The 192.168.1.10 255.255.255.0 portion is the bridge interface and mask. The IP range 192.168.1.100 192.168.1.150 is the range of IP addresses that will be assigned to clients.
- push: are directives to add networking options for clients.
- user and group: configure which user and group the openvpn daemon executes as.
We can now restart the server so that our changes take effect:
$ /etc/init.d/openvpn restart
If this fails, check /var/log/daemon.log for errors. It is likely that you get errors similar to:
Mar 15 19:28:52 dev ovpn-server[7786]: openvpn_execve: external program may not be called due to setting of --script-security level Mar 15 19:28:52 dev ovpn-server[7786]: script failed: external program fork failed
This can be fixed by altering the /etc/default/openvpn file and amend the OPTARGS="" entry as follows:
OPTARGS="--script-security 2"
Configure OpenVPN Client
The VPN client will also need a certificate to authenticate itself to the server. Create the certificate on the server as follows (replacing "hostname" with the name of the client):
$ cd /etc/openvpn/easy-rsa/ source vars ./pkitool hostname
Now copy the following files from the /etc/openvpn/easy-rsa/keys directory to /etc/openvpn on the client (note that a secure method of transfer is highly recommended!):
- hostname.crt
- hostname.key
- ta.key
- ca.crt
With the server configured and the client certificates copied over, create a client configuration file by copying the example.
$ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/
Now edit /etc/openvpn/client.conf changing the following options:
dev tap remote vpn.example.com 1194 cert hostname.crt key hostname.key tls-auth ta.key 1
Remember to replace vpn.example.com with the hostname of your VPN server as it is seen from the Internet (this could be the firewall if the firewall port-forwards port 1194 to the VPN server inside its LAN), and hostname.* with the actual certificate and key filenames.
Now simply start openvpn on the client in the same way you did for the server.
Windows Client Notes
On a Windows client it is necessary to name the config file hostname.ovpn and the client must be run with "administrator" privileges otherwise appropriate routes cannot be configured. This can be done by right-clicking the shortcut and selecting "Run as administrator"
Acknowledgements
This guide is unashamedly based upon the amazing efforts made by the Ubuntu community, namely:
https://help.ubuntu.com/community/OpenVPN
https://help.ubuntu.com/9.10/serverguide/C/openvpn.html
Acer Aspire One and SD cards
There are two SD card readers built into some Acer Aspire One systems. The one on the left side is designed to act as more long-term storage (the card left in between netbook uses) the right side, however, is designed to be hot-swappable and supports other types of storage cards. The issue results in SD cards not being usable when the netbook booted up unless a SD card was plugged in before boot, at which point it worked as expected.
There is an Ubuntu bug report detailing the issue and potential fixes:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/271019
On my Acer Aspire One, the fix was an entry added to GRUB's /boot/grub/menu.lst file, adding "pciehp.pciehp_force=1" to the end of the kernel line. However, this change would not take effect at the next kernel update. Ubuntu's grub update script uses markers to update kernel entries - according to its comments:
### BEGIN AUTOMAGIC KERNELS LIST ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default options below ## DO NOT UNCOMMENT THEM, Just edit them to your needs
The entry needed was:
## additional options to use with the default boot option, but not with the ## alternatives ## e.g. defoptions=vga=791 resume=/dev/hda5 # defoptions=quiet splash
The first few lines begin with a double hash (##) - these are the real comments, the entries beginning with a single hash (#) are the lines used by the update-grub script. The change to be made resulted in the following:
## additional options to use with the default boot option, but not with the ## alternatives ## e.g. defoptions=vga=791 resume=/dev/hda5 # defoptions=quiet splash pciehp.pciehp_force=1