Archives 2013

Scenario: You have an Ubuntu Linux server. The storage system is a large RAID array, partitioned as a GPT disk and it has two partitions on it – a small boot partition and the second partition is setup for use with LVM with one or more Logical Volumes in it.

You’re starting to run out of space and intend to expand the system by adding one or more disks to the array. Once you’ve done this, you will obviously need to extend the partition to use the new space, but GPT is a slightly different kettle of fish to regular partitioning, and being a server you don’t have a GUI to use traditional tools.

So how do you do this?

The basic flow of necessary steps is essentially:

1. Resize the array by adding new disks (not covered by this article).
2. Resize LVM partition to use the new space in the array.
3. Resize the Physical Volume in the LVM partition to use the newly resized space.
4. Resize the Logical Volume(s) inside the Volume Group to their new sizes.
5. Resize the filesystems in each Logical Volume to match their sizes.

WARNING: You are about to manipulate the partitions and data on your drive. Any mistake made during that process can result in data loss. Following this article is done at your own risk and no responsibility for any errors or data loss will be accepted by the author. Always have backups before performing any major changes to your drive’s geometry. You have been warned!

The instruction for this article was tested on the following server:

• Ubuntu 12.04.3 LTS Server
• An Intel SRCSATAWB PCI-E RAID controller (LSI chipset) – presents a single large drive to the OS
• The array is a RAID6 array with eight 2TB drives (two drives were global hotspares)
• The array was expanded from 8TB to 10TB by converting one of the global hotspares to an active member

As always, while this article is written with Ubuntu in mind, it should apply equally to just about any distribution.

So let’s begin:

1. Using the instruction applicable to your RAID array, expand the array with new drives and begin the rebuild process. Note that it may take several hours or even days (!) to expand your array depending on what type of array you are using and the size of of your array members. You cannot proceed until the rebuild has concluded.
   
2. Once the array has finished rebuilding, you will need to reboot into Recovery Mode or reboot into a Live CD/USB environment, as it is not possible to resize a partition while it is online.
   
3. Since this is a GPT-partitioned disk, we have to use the Parted tool instead of FDisk. In your Recovery Mode or Live environment, open a terminal if you haven’t already got one and launch Parted to examine your array by typing in:
   
   $ sudo parted /dev/sda
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
   
   (If your array’s volume is not /dev/sda, substitute the appropriate device name)
   
4. Now we have a “(parted)” prompt. First up, we need to switch the units of measurement we’re using to sectors. Do that by issuing the following command:
   
   (parted) u s
   
5. Now list the existing partitions using the “print” command. You will see something similar to the following:
   
   (parted) print
Model: INTEL SRCSATAWB (scsi)
Disk /dev/sda: 19521474560s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 2048s 1953791s 1951744s ext4 Boot boot
2 1953792s 19521474526s 19519520735s MYSERVER_HDD lvm
   
   NOTE: You may be shown a warning message advising that the GPT table is not at the end of the disk, saying that the disk size is smaller than the system expects it to be (because you resized your array, remember?). It will ask you if you wish to fix this. Type in “F” and hit enter. You may then be warned that the kernel is not yet aware of changes being made. Respond to this with Ignore by typing in “I” and hit enter. You may be prompted with the latter message several times whilst using Parted. Respond “Ignore” to it each time. In this environment, the current kernel does not need to be aware of the changes because we’re going to reboot at the end of it anyway.
   
6. Make a note of the items that are highlighted in red above, namely the total sectors of the device (which represents the total size of your newly expanded array) and the start sector of the second partition. Please double-check your figures and make sure they are right. Any mistakes here can DESTROY YOUR DATA.
   
7. Now we’re going to resize the second partition to use all of the newly created space in the array. Unfortunately GPT has no ability to resize. Instead you must remove the partition and recreate it. Don’t worry, as scary as it sounds, this process will NOT change any of the data on the drive. It simply deletes the geometry data relating to the start and end of the partition on the drive only. Remove the second partition with the following command:
   
   (parted) rm 2
   
8. Now let’s create a new partition to replace it. Type in the following:
   
   (parted) mkpart
   
9. You will be asked for name for the partition. Give it the same name you had for it before, or specify a new name if you like:
   
   Partition name?  []? MYSERVER_HDD
   
10. You will then be asked about the file system type. You can’t specify LVM here, so just hit enter to accept “ext2″ – we’ll change it later:
    
    File system type?  [ext2]?
    
11. You will then be asked for the start sector. Specify the value of the start of the second partition that you recorded earlier (don’t write the letter “s” on the end):
    
    Start? 1953792
    
12. You will then be asked for the end sector. Specify the value of the total size of the drive that you recorded earlier minus one. If you specify the actual value, you will get an error saying that the value is “outside of the device” which is why you specify a value just inside that limit.
    
    End? 19521474559
    
13. You will then be told that the system cannot actually make a partition up to that location (because there’s another partition on the disk taking up space), so the system will offer the next closest value which will just happen to be the maximum space remaining on the array. Simply respond “Y” for Yes.
    
    Warning: You requested a partition from 1953792s to 19521474559s.
The closest location we can manage is 1953792s to 19521165533s.
Is this still acceptable to you?
Yes/No?
    
14. Now we need to change the partition type to LVM as follows:
    
    (parted) toggle Partition number? 2
Flag to Invert? lvm
    
15. We’re now done with our partitioning so quit parted with the quit command:
    
    (parted) quit
    
16. Reboot your server and boot up as normal. If you check your drive using parted or fdisk, it should now show that the total partition size includes the newly added space in your array, but nothing is using it yet. Now it’s time to tell LVM to use the new space by resizing the Physical Volume with the following command:
    
    $ sudo pvresize /dev/sda2
    
17. Once completed, you can now check out the new free space (shown as free extents) in the LVM Physical Group by issuing the command:
    
    $ sudo pvdisplay
    
18. Now we can start allocating this newly acquired free space to our LVM Logical Volumes. First up, let’s get a list of all our defined Logical Volumes:
    
    $ sudo lvdisplay
    
19. Note down the “LV Name” of each Logical Volume you wish to add space to.
    
20. Now let’s resize the Logical Volume. There are two ways you can do this. One method is to specify an absolute value that defines the new size of that Logical Volume, or specify a value that will add to the existing size of it. In this first example, I’m going to change the size of my Logical Volume called /dev/myserver/mylogicalvolume to be an absolute size of 20 gigabytes:
    
    $ sudo lvextend -L20G /dev/myserver/mylogicalvolume
    
    …which will make the /dev/myserver/mylogicalvolume Logical Volume 20 gigabytes in size regardless of its previous size. It does NOT add to the existing size.
    
    Alternatively to add space to the existing size using the following command instead:
    
    $ sudo lvextend -L+20G /dev/myserver/mylogicalvolume
    
    (note the plus sign between the -L and the 20G)
    
    …which will add 20 gigabytes of space to the /dev/myserver/mylogicalvolume Logical Volume. If it was 10 gigabytes in size before, it will now be 30 gigabytes in size.
    
    Alternatively, if you wish to allocate all remaining free space to a Logical Volume, issue the following command:
    
    $ sudo lvextend -l +100%FREE /dev/myserver/mylogicalvolume
    
    (notice that the parameter is a lowercase L instead of a capital L)
    
    Repeat for all Logical Volumes you are extending. There are other ways to allocate space as well, but the above are the most common methods that would be used. See the man page of the lvextend command for more information.
    
21. You can confirm the new sizes for each Logical Volume by issuing the following command:
    
    $ sudo lvdisplay
    
22. We’re nearly there! All that is left to do is now to resize the filesystems containing within our Logical Volumes to use the newly allocated space. Again, using the LV Names you recorded earlier, specify the following command for each Logical Volume you have modified:
    
    $ sudo resize2fs /dev/myserver/mylogicalvolume
    
23. Once you have expanded the filesystems on all your Logical Volumes, you can check the free space on each of your filesystems by issuing the following command:
    
    $ df -h
    
24. And that’s it! You have successfully expanded your LVM partition on your GPT-partitioned array! Pat yourself on the back. You are done.

The scenario is simple: You have a kiosk or display machine showing information, eg: a self-updating webpage. On a schedule you want to launch an Impress or PowerPoint presentation on the display which will loop. You want that loop to only run for a few minutes before terminating and going back to what was originally being displayed.

How do you do this?

Procedure:

1. First of all you need a presentation file. If the original is from PowerPoint, load it into Impress and re-save it as an ODP file.
   
2. Make sure that your presentation has been cleared of all “On Click” events, ie: All slides should advance automatically after X seconds. Any animated components within a slide should be updated to occur after the last action.
   
3. Make sure your presentation is set to automatically loop at the end (Slideshow Menu->SlideShow Settings->Type set to Auto with zero seconds).
   
4. Save your changes.
   
5. Copy your presentation over to your kiosk machine.
   
6. Using SSH or a local terminal, bring up the crontab into your favourite text editor (default is Nano with Ubuntu) with:
   
   $ crontab -e
   
7. Now, assuming your presentation is at /home/kiosk/Documents/MyPreso.odp, add  the following lines:
   
   00 10 * * * DISPLAY=:0 /usr/lib/libreoffice/program/simpress -show /home/dashboard/Documents/MyPreso.odp --norestore
15 10 * * * /usr/bin/killall soffice.bin
   
   What the above lines will do is launch Impress to open your MyPreso presentation in Show Mode at 10:00am on the dot on the first display (screen zero). The “–norestore” parameter prevents LibreOffice from asking if you want to recover any files which will occur if you terminate LibreOffice instead of closing the app as normal (we can’t because it’s a kiosk, remember?). Then, at 10:15am, the LibreOffice task will be terminated, thus ending the looping presentation.
   
8. Now save your changes and exit the text editor. if using Nano, you’d press CTRL+X, then “Y” and then Enter
   
9. Now test your schedule.

That’s cool. Now can we configure it to have a different presentation to run each day?

This is quite easy to do.

1. First generate all the different presentations you will need to run on each day of the week. Name them accordingly. In this example we are naming them MyMondayPreo.odp, MyTuesdayPreso.odp, and so forth.
   
2. Now modify the crontab to look like the following:
   
   00 10 * * 1 DISPLAY=:0 /usr/lib/libreoffice/program/simpress -show /home/dashboard/Documents/MyMondayPreso.odp --norestore # Monday
00 10 * * 2 DISPLAY=:0 /usr/lib/libreoffice/program/simpress -show /home/dashboard/Documents/MyTuesdayPreso.odp --norestore # Tuesday
00 10 * * 3 DISPLAY=:0 /usr/lib/libreoffice/program/simpress -show /home/dashboard/Documents/MyWednesdayPreso.odp --norestore # Wednesday
00 10 * * 4 DISPLAY=:0 /usr/lib/libreoffice/program/simpress -show /home/dashboard/Documents/MyThusdayPreso.odp --norestore # Thursday
00 10 * * 5 DISPLAY=:0 /usr/lib/libreoffice/program/simpress -show /home/dashboard/Documents/MyFridayPreso.odp --norestore # Friday
15 10 * * * /usr/bin/killall soffice.bin
   
   You will notice that each line has one of the asterisks replaced with a number 1 through 5. This tells cron only to run that schedule on the day specified. In this case, the 1 represents Monday, the 2 is Tuesday, the 3 is Wednesday and so forth. Saturday is 6 and Sunday is both 1 or 7.
   
   You may be wondering why we only have one killall command instead of five? We don’t need five as the command to kill LibreOffice is the same each time, so it doesn’t need a day designation – it will run every day at 10:15am.
   
3. Save your changes and test.

Now you can schedule your presentations to appear and disappear as required without manually interrupting the normal display on that kiosk. Naturally these instructions can be adapted for other uses.

So, you decide to install a new package on your system, or perhaps update your system with some outstanding updates. You either use the Software Centre or the Apt-Get command from a terminal to do this and you are suddenly greeted with the following error:

Failed to exec method /usr/lib/apt/methods/
E: Method  has died unexpectedly!
E: Sub-process  returned an error code (100)
E: Method /usr/lib/apt/methods/ did not start correctly

And everything stops. Repeating the command produces the same error over and over.

What just happened and how do you fix this?

What has happened is that one or more of your cached sources lists has corrupted itself and no amount of re-running apt-get update is going to fix this. We need to delete the cache of lists and get apt-get update to re-download them in their entirety – nice and fresh.

1. In a terminal, type in:
   
   $ sudo rm -rf /var/lib/apt/lists/*…and hit Enter.
   
2. Now type in:
   
   $ sudo apt-get update
   
   …and hit Enter. You will notice that this takes a bit longer than usual to complete.
   
3. Now try your package installation or system update again:
   
   $ sudo apt-get install <name of the package you tried to install before>
   OR
   $ sudo apt-get upgrade
   
   …and this time you will see Apt behaving itself again.
   
4. Pat yourself on the back. Crisis resolved.

The ubiquitous Sony PlayStation3 DualShock controller. This controller has been around for ages now and IMO it’s one of the nicest multi-button game controllers out there. One of its nicer features is that it has USB and Bluetooth connectivity.

It’s already been proven that you can connect a PS3 controller to Ubuntu using a standard USB cable, which is fine, but it’d be kinda cool to use Bluetooth as well. The thing is that the PS3 controller doesn’t follow the complete Bluetooth specification with regards to pairing. The reason for this is deliberate – you don’t want people being able to steal control of your PS3 controllers or your PS3 remotely, so pairing is performed manually using the USB cable. Once paired that way, the cable can be disconnected and you can continue using Bluetooth instead.

So can we replicate this in Ubuntu? Can we pair a controller via USB and then continue to use it via Bluetooth? Thanks to the QTSixA project, we can!

Prerequisites:

• One PlayStation3 DualShock controller or compatible equivalent
• One normal USB charge cable
• Any Bluetooth adapter on your desktop PC or in-built in your laptop

Procedure:

1. First we need to add the QTSixA project’s PPA to your system. Open a terminal and type in the following and hit Enter:
   
   $ sudo add-apt-repository ppa:falk-t-j/qtsixa
   
2. You will be prompted about adding the repository. Just hit Enter:
   
   You are about to add the following PPA to your system:
Packages for QtSixA and sixad software

To enable this repository in Karmic and Lucid:
sudo add-apt-repository ppa:falk-t-j/qtsixa

In Jaunty and Intrepid, add the line to the software sources:
deb http://ppa.launchpad.net/falk-t-j/qtsixa/ubuntu UBUNTU_VERSION main

More info: https://launchpad.net/~falk-t-j/+archive/qtsixa
Press [ENTER] to continue or ctrl-c to cancel adding it
   
3. Once the PPA has been added, have your system update its cache of available software from the PPA’s with:
   
   $ sudo apt-get update
   
4. Now let’s install the QTSixA application:
   
   $ sudo apt-get install qtsixa
   
5. Now the fun can really begin! Get your PS3 controller and connect it to your system with its USB charge cable. The four red LED’s on the back of the controller will begin to flash and if you issue an lsusb command you will see the controller listed:
   
   $ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 003: ID 0480:a006 Toshiba America Info. Systems, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 012: ID 054c:0268 Sony Corp. Batoh Device / PlayStation 3 Controller
Bus 001 Device 003: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX
Bus 001 Device 004: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser
Bus 001 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
   
6. Now let’s pair the controller to your PC’s Bluetooth adapter:
   
   $ sudo sixpair
Current Bluetooth master: 00:25:56:2e:7f:52
Setting master bd_addr to 00:1b:dc:00:3c:f1
   
7. We’re nearly there! Now we just need to activate the controller so we can start using it! At this point you can now disconnect the USB cable (you don’t have to, especially if you’re still charging it) and enter the following command:
   
   $ sixad --start
sixad-bin[13374]: started
sixad-bin[13374]: sixad started, press the PS button now
   
8. When prompted, press the PS button on your controller to activate it and the terminal will show something similar to the following:
   
   sixad-sixaxis[13430]: started
New Device: 00:1E:3D:AA:82:6C PLAYSTATION(R)3 Controller (Bluetooth)
sixad-sixaxis[13430]: Connected 'PLAYSTATION(R)3 Controller (00:1E:3D:aa:82:6c)' [Battery 05]
   
9. That’s it! Your PS3 controller is now connected! You can now start using it in games that support using it.

Questions:

• Can you pair multiple controllers?
  Yes! Just repeat the pairing process for all new controllers. The appropriate red LED number will light up on the controller to indicate which one it is.
  
• The terminal is nice, but is there a GUI application to manage the controllers as well?
  Yes! Just launch the QTSixA application from the Ubuntu Dash menu launcher.
  
• I don’t want to use my controller on my PC anymore – how do I reconnect it to my PS3?
  Simply reconnect the controller to your PS3 via its USB charge cable and turn your PS3 on. This will immediately change its pairing to the PS3 and prevent it connecting to your PC anymore.
  
• Can I have the controller paired with the PS3 and the PC at the same time?
  No. The controller only allows for one master.
  .
• I notice there’s a number of extra applications in the QTSixA suite. What are they for?
  The package allows for connecting other PlayStation accessories such as the keyboard and remote as well as extended features for the controller itself. Refer to the documentation of the QTSixA project for more information.

Scenario: You’ve got some Postfix mail servers running with Postgrey for anti-spam greylisting. They’re all using older versions of Ubuntu such as 10.04 LTS. You’ve decided that it’s time to upgrade them to the next LTS, Ubuntu 12.04.

You do the upgrade and it goes without a hitch. You restart the server, everything looks good, until you start seeing this message in your server’s mail log:

Jan 23 21:17:58 mymailserver postfix/smtpd[7976]: connect from somecompany.com[100.200.300.400]
Jan 23 21:17:59 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:17:59 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:00 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:00 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:00 mymailserver postfix/smtpd[7976]: NOQUEUE: reject: RCPT from somecompany.com[100.200.300.400]: 451 4.3.5 Server configuration problem; from=<m-1wu7GywwdBK9XOl40cdonjrOvQVbXrSQjrNIttfwaHqBuxTEiR4njb_
n@bounce.somecompany.com> to=<myrecipient@mycompany.com> proto=ESMTP helo=<mail.somecompany.com>
Jan 23 21:18:05 mymailserver postfix/smtpd[7976]: disconnect from somecompany.com[100.200.300.400]
Jan 23 21:18:10 mymailserver postfix/smtpd[7955]: connect from unknown[200.300.400.500]
Jan 23 21:18:11 mymailserver postfix/smtpd[7955]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:11 mymailserver postfix/smtpd[7955]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: NOQUEUE: reject: RCPT from unknown[200.300.400.500]: 451 4.3.5 Server configuration problem; from=<someone@anothercompany.com> to=<myrecipient@mycompany.com> proto=ESMTP helo=<m
ail.anothercompany.com>
Jan 23 21:18:12 mymailserver postfix/smtpd[7955]: disconnect from unknown[200.300.400.500]
Jan 23 21:18:17 mymailserver postfix/smtpd[7976]: connect from mta.ilikecheese.com[300.400.500.600]
Jan 23 21:18:18 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:18 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:19 mymailserver postfix/smtpd[7976]: warning: connect to 127.0.0.1:10023: Connection refused
Jan 23 21:18:19 mymailserver postfix/smtpd[7976]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Jan 23 21:18:19 mymailserver postfix/smtpd[7976]: NOQUEUE: reject: RCPT from mta.ilikecheese.com[300.400.500.600]: 451 4.3.5 Server configuration problem; from=<someone@thatcompany.com> to=<myrecipient@mycompany.com> pro
to=ESMTP helo=<MTA.thatcompany.com>
Jan 23 21:18:20 mymailserver postfix/smtpd[7976]: disconnect from mta.thatcompany.com[300.400.500.600]

You almost have a heart attack – every single email is bouncing back and it’s clear that it’s something to do with your upgrade. What went wrong? The errors refer to a configuration issue, but you didn’t change any of the configuration in your upgrade!

Closer inspection reveals that for some reason, Postfix is unable pass messages onto Postgrey which is a local service running on port 10023 by default on Ubuntu systems. If you try telnetting to port 10023 on 127.0.0.1 , you also get a “connection refused” error. So what’s happened?

The answer is that somewhere between Ubuntu 10.04 and Ubuntu 12.04, Postgrey changed the protocol it binds on. It now binds to IPv6 instead of IPv4 so we need to make some minor changes to Postfix’s configuration to get Postgrey working again.

1. First up, we need to stop mail being bounced. It’s better to have sending servers pool up mail a little and then send it all through at once later, so at a Terminal prompt on your server, type in:
   
   $ sudo service postfix stop
   
2. Now we need to edit Postfix’s configuration file:
   
   $ sudo nano /etc/postfix/main.cf
   
3. Scroll down until you can see the line inside the “smtp_recipient_restrictions” section that directs Postfix to send mail to Postgrey for checking (or use CTRL+W to search for it), which looks like this:
   
   check_policy_service inet:127.0.0.1:10023,
   
4. And now modify that line to look like the following. This will make Postfix pass on the mail to Postgrey using IPv6 instead of IPv4:
   
   check_policy_service inet:::1:10023,
   
5. Now on a new line outside of the “smtp_recipient_restrictions” section, add the following line:
   
   inet_protocols=all
   
6. Save your changes by pressing CTRL+X, then “Y” and then Enter.
   
7. Now we can restart Postfix with:
   
   $ sudo service postfix restart
   
8. Now start tailing your log with the “follow” parameter using the following command:
   
   $ tail -f /var/log/mail.log
   
9. Now send a test email and watch what new information appears in the terminal log. This time the mail should be successfully received and processed as normal.
   
10. Pat yourself on the back and breath a sigh of relief.