Just as a quick note to myself because I’m doing this more often in server setups these days (which nevertheless is still infrequent enough that I need to drop notes for myself) – to create a symbolic link (symlink) on an Ubuntu server via the terminal, in particular to link to a folder, I need to use the ln command combined with the -s switch (The ln link command has a whole lot of uses, but we’re interested in symbolic links here).
The syntax is as follows:
ln -s <real folder> <link folder>
What the above achieves is a pseudo <link folder> which whatever you do inside it, actually happens in <real folder>. Nifty.
You can verify the symbolic link with the command ls -l which will show an arrow to where the link points.
Related Link: http://manpages.ubuntu.com/manpages/vivid/man1/ln.1.html
Just a quick reminder to myself as to how to set an hourly cron on an Ubuntu Server instance using the standard Crontab mechanism (use crontab -e to edit your crontab).
Now “* */1 * * * command.sh” (similar to how you would do one for every couple of minutes) may look very tempting at first glance, but this is in fact wrong. While what you are doing here does indeed say to run every hour (*/1), the first * means that it needs to run every minute. So what you are basically doing is runing the command at the start of each minute for each and every hour.
Not exactly what we’re looking for.
Instead, the correct way would be to simply specify the minute to run at – so say 0 to indicate the top of the hour. So a correct string to achieve a scheduled task that runs once an hour would be:
0 */1 * * * command.sh
A small, but significant point to remember then!
(Also, useful to remember that if you want to run your command with administrator privileges, you need to edit your crontab using sudo crontab -e. This crontab is separate for one edited without the sudo command!)
Related Link: https://help.ubuntu.com/community/CronHowto
It’s pretty seldom that you have to install packages that aren’t part of the official repositories (for which apt-get is king), but every now and then you will be presented with a .deb application installer file and told to install it on your server.
Luckily this is pretty painless, so long as you know the correct command, which is exactly why I’m noting it down here for future reference.
Packages are manually installed via the dpkg command (Debian Package Management System). dpkg is the backend to commands like apt-get and aptitude, which in turn are the backend for GUI install apps like the Software Center and Synaptic.
To install a .deb file, run:
sudo dpkg -i myInstaller.deb
If dpkg reports an error due to dependency problems, you can run:
sudo apt-get install -f
Running this should download the missing dependencies and configure everything automatically. If however this step reports an error… well let’s just say that you’ll have to sort out the dependencies yourself, something often referred to as “dependency hell” in the support forums!
Conversely, to uninstall a package, run dpkg with -r:
sudo dpkg -r myInstaller
An old one, but for my own reference purposes, worth noting down here in these pages. In order to extract the contents of a .tar.qz archive file, turn to the tar command (“man tar” for options as per usual):
tar -xvzf archivefile.tar.gz -C /home/craig/downloads
In this example we’ve extracted the contents of archivefile.tar.gz to the /home/craig/downloads directory. (If we left out the -C directive then the operation would simply have extracted the archive contents to the working directory.)
To explain the archivefile.tar.gz file itself, essentially tar collected all the files into one package followed by a call to gzip which then compressed the tar file. (This is often referred to as a tarball in the Linux world.)
To extract the files making up this tarball, we used the following parameters in our call to tar:
x: tar can collect files or extract them. x does the latter.
v: makes tar talk a lot. Verbose output shows you all the files being extracted.
z: tells tar to decompress the archive using gzip
f: this must be the last flag of the command, and the tar file must be immediately after. It tells tar the name and path of the compressed file.
Obviously -v isn’t necessarily, but it is helpful to see what is going on. So in summary, to extract a .tar.gz file, run:
tar -xvzf [archiveFile].tar.gz
So you’ve loaded up a copy of Ubuntu Server 14.04 (Trusy Tahr) on your VM, and because you don’t feel like doing everything via the command line, you now want the ease of use that Webmin supplies.
No problem, grabbing it and installing Webmin on an Ubuntu Server remains a relatively simple thing to do.
First, log into your server and edit the sources file:
sudo nano /etc/apt/sources.list
Add this line:
deb http://download.webmin.com/download/repository sarge contrib
Save the file and exit the nano editor. Next we need to grab and install the PGP key:
wget -q http://www.webmin.com/jcameron-key.asc -O- | sudo apt-key add -
With that all done, now it is a simple matter to install the latest version of Webmin as you would any other Ubuntu package:
sudo apt-get update sudo apt-get install webmin
Once the install has completed, you should be able to access the webmin console by logging in to either https://localhost:10000/ or https://yourIPaddress:10000/ (Note the HTTPS requirement).
Remember, you need to log in with a user account that has sudo rights and of course a password (i.e., don’t log in with the root user).
Related Link: http://www.webmin.com/
My Linux knowledge is rather rusty, so needless to say, I managed to frustrate myself by accidentally halting a running program (VMware Tools installer) by pressing CTRL+Z whilst working on one of our Ubuntu Server installs (12.04) the other day.
So as a quick reminder to myself more than anything else, here is how to get back control, or start if you will, a halted program (job in this particular parlance).
First, to see a list of all jobs, run:
You’ll see a list of all available jobs, with their ID on the left hand side of the listing. If you want to continue the halted program in the background (let it do its business and then switch back to it later), enter:
where [number] is the number identifier of the job the run in the background. Of course, you’ll probably actually want to have the program back in the foreground (like I needed to), which in that case meant I had to run:
Easy as that. For quick reference, here is a list of general job control commands available to you:
Every now and then I need a new SSL certificate for a server, and of course therefore need to produce the relevant certificate signing request (CSR) for processing. So this little note sums up the Ubuntu Server (12.04 LTS) process in a nutshell, i.e. so that I don’t keep having to head out to Google to look it up! (Most of this is taken pretty much directly from the Ubuntu Server Guide just by the way)
Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key. You have two options when it comes to keys in terms of either running them with a passphrase or without. With a passphrase is obviously more secure because it becomes harder to compromise the key, but without is a heck of a lot more convenient because you don’t need to enter a passphrase every time you start up a secure service – in other words exactly what your Apache, Postfix, Dovecot service daemons require!
To generate the keys for the Certificate Signing Request (CSR) run the following command:
openssl genrsa -des3 -out my.server.co.za.key 2048
During this process you will be asked to enter a passphrase containing at least 8 characters. Also, you’ll notice that I like to name my SSL-related files using the domain that I am securing, so in this example the end result would a SSL certificate issued for my.server.co.za. (Of course, this is completely personal preference when it comes to a file naming scheme).
Now that we have a secure key, the idea is to generate an insecure version of it, essentially a key without a passphrase. To do this, run:
openssl rsa -in my.server.co.za.key -out my.server.co.za.key.insecure mv my.server.co.za.key my.server.co.za.key.secure mv my.server.co.za.key.insecure my.server.co.za.key
As you can see, we shuffled the file names so that the insecure CSR is now the .key file, whilst we’ve save the secure version for safekeeping as .key.secure.
Finally, to generate the actual Certficiate Signing Request (CSR), we run the following command:
openssl req -new -key my.server.co.za.key -out my.server.co.za.csr
You’ll be asked to fill in a whole lot of information (after being challenged to provide the passphrase that you entered when creating the original key), and once the .csr file has been generated, you can now safely submit it either to a CA for processing, or for use to create your own self-signed certificate from it.
Useful hint, one of the questions asked during CSR generation will be “Common Name”. The input here MUST be the fully-qualified domain name (FQDN) for the website you will be using the certificate for (e.g., “www.myserver.co.za”). Do not include the “http://” or “https://” prefixes in your common name. Do NOT enter your personal name in this field. If you are requesting a wildcard certificate, add an asterisk (*) on the left side of the common name (e.g., “*.domainnamegoeshere.com”). This will secure all subdomains of the common name. Finally, if you enter www.myserver.co.za as the common name, then the certificate will secure both “www.myserver.co.za” and “myserver.co.za”.
Useful to know.
Related Link: Ubuntu Certificates and Security
The problem with running your Media Center PC on the floor next to the television is that your little three year old girl who likes to do things without any assistance at all, will press every and any button at random in the hopes of loading up My Little Pony: Friendship is Magic.
One such session caused the boot flag to corrupt on my shiny XBMCbuntu installation, meaning that on boot, the PC simply sat there with the disastrous fail message of “Error: File not found. Grub rescue…” blinking back at me.
Right, so the Grub boot loader is broken. How do we fix?
Well first, you will need a LiveCD, which you should have because you would have used it to setup the media server in the first place. Once you’ve selected the try (no install) option from the LiveCD boot menu (remember, you’ve changed the BIOS to boot up from either the CD or USB drive in order to launch this menu), access a terminal by pressing ALT+CTRL+F1.
You need an Internet connection on the box because the next step is to download and install the very nifty Boot Repair utility:
sudo add-apt-repository ppa:yannubuntu/boot-repair sudo sed 's/trusty/saucy/g' -i /etc/apt/sources.list.d/yannubuntu-boot-repair-trusty.list sudo apt-get update sudo apt-get install -y boot-repair && (boot-repair &)
Note that we manually tweak the apt sources.list to change our entry from trusty to saucy before attempting to grab boot-repair. If you are using an older version of XBMC you can probably skip this, but I’m using XBMCbuntu 13 which is obviously build on top of the Trusty Tahir build of Ubuntu. (The reason for this is that Boot-Repair hasn’t yet been made available for the latest version of Ubuntu)
Also, actually running boot-repair might fail for you (failed to initiated graphics), in which case you need to attempt the following:
Hit ALT+CTRL+F7 to jump back to the visual XBMC application. Select Exit from the shutdown menu, which should then drop you into a Login menu. On the top right of the screen, change the selected login target from XBMC to XBMCbuntu. Login using username = xbmc and password = ” (blank). Once in the desktop, locate and run the boot-repair utility. If you can’t spot it, open the UXTerm terminal and run boot-repair.
With Boot Repair now up and running, click on the “Recommended Repair” option. This will reinstall Grub and set the pointer to point to the correct location, and in so doing fix your boot issue. (If it doesn’t, go into the “Advanced Option” and tinker around a bit to best suit your environment).
Once you see a message reading “Boot successfully repaired”, you can safely remove the LiveCD or USB drive, and reboot your machine.
Crisis averted, My Little Pony: Friendship is Magic is back on demand! :)
Because XBMCbuntu is essentially a light-weight Ubuntu install configured to run XBMC at startup, you have access to most of the basic commands that a normal Ubuntu box would have. In other words, you have access to all the normal niceties of Ubuntu – like the crontab, the perfect way of scheduling an automatic shutdown of your XBMC media server. You know, because a) you like the idea of saving electricity, or b) your old hardware powering your media server is a little… well noisy.
Anyway, bring up a terminal by pressing ALT+CTRL+F1. Your login details will be those that you setup during install. If you don’t have those on hand, then you could try the default XMBC root user which has the details of username=’xbmc’ and password=” (blank).
Now to edit the crontab (as sudo of course) to set up our scheduled task:
sudo crontab -e
Add the shutdown rule as follows. In this case, it is set to run the shutdown command every evening at 1 o’clock in the morning – everyone should be asleep by then, movie nights done and dusted for sure! (Obviously you can set whatever times you want, play around a little if you must.)
0 1 * * * /sbin/shutdown -P now
Save the crontab and on exit of the editor, you should see the line saying “Installing new crontab”. You can obviously test the command yourself right then and there by running:
sudo /sbin/shutdown -P now
Although this will of course shutdown your machine. If you just want to jump back to XBMC, hit ALT+CTRL+F7.
A useful tip if your small child isn’t quite capable of controlling XBMC just yet! :)
Related Link: http://wiki.xbmc.org/?title=XBMCbuntu