Disable internal audio

Have been working with Ardour lately and the multiple audio devices (internal + PCI) have been causing issues both on output and input. The easiest workaround is removing totally the unused sound card, which in my case was the internal Intel HDA. The single step required was to blacklist the module of the sound card. You can identify the module by “lspci” and then blacklisting the module is straight forward:

vi /etc/modprobe.d/blacklist

and add the line

blacklist <module name>

A single reboot should do the job or you could unload the module instantly. Although, reboot would confirm whether the blacklist function worked or not.

Advertisements

Remote cPanel backup via FTP

Here is the scenario:

– Domain that needs to be backed up (public_html, mail, database).
– Only access available via cPanel and FTP.
– Need automated daily full backup.

Solution:

– Take full backup on server and compress its contents (cronjob on remote server)
– Download via FTP the compressed file to the local machine (cronjob on local machine).
– Delete compressed file.

There might be tools that do this, although I didn’t come across any while looking on the web. I implemented a simple solution based on bash scripts that gets the task done.

backup.sh: Goes on the remote server to run as a cronjob.
ftp.sh: Runs locally (on the machine that will store the backup) as a cronjob.
.netrc: Defines the FTP account details (stored in /home/$user/.netrc)

Gmail SMTP relay with Postfix

The following configuration has been performed in Debian but should apply in any Linux distro with Postfix installation. The task quite simple: use Gmail as SMTP relay for outgoing email traffic.

1) At first place I had to install the following packages and turn off sendmail:

apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules
service sendmail stop

2) Then edit the configuration file at /etc/postfix/main.cf by adding the following options at the end of the file:

# Gmail SMTP relay
relayhost = [smtp.gmail.com]:587
smtp_use_tls=yes
smtp_sasl_auth_enable = yes 
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_sasl_security_options =

3) Create the authentication file at /etc/postfix/sasl_passwd and set the right permissions:

[smtp.gmail.com]:587    <username>@gmail.com:<password>
chmod 400 /etc/postfix/sasl_passwd

Make sure the file is owned by the user who runs the Postfix daemon.
4) Reload Postfix:

service postfix reload

5) Confirm the configuration is actually working by sending a test mail:

echo "Test mail from postfix" | mail -s "Test Postfix" pkritikakos@isbs.gr

The sender of the email should be the given Gmail account. Also, in the “Sent” folder of the Gmail account you should see the email you have sent with Postfix.

If your domain is using Gmail’s infrastructure for handling emails, you can replace @gmail.com with your domain and use the corresponding account details.

NOTE: This configuration will be sending any system message as “username@gmail.com” and therefore is not advised to be used in multi-user environment.

Converting OS X .plist to XML

The failure of my MacBook Pro seems that it didn’t cost much in terms on data loss, actually all the really crucial data were there. There are though some bits here and there that need to be moved over to my Linux box. One of the most important for everyday use the was the feed list for my RSS Aggregator. I was using the elegant, nice and simple NewsFire which uses binary plists (XML-like) for storing the feed list and I was never bothered exporting the feed list to OPML. The plist command in OS X can convert the .plist file into a .xml file, however I had no other Mac to do this operation or copy over the plist and export in OPML from there. Therefore I had to find a workaround for getting the plist working on RSSOwl or Liferea. Found the Perl plutil for Linux which converted the binary plist to standard XML. RSSOwl managed then to import the XML with all the blogs’ feeds as on NewsFire.

Regarding liferea, it wouldn’t import the XML file as it wasn’t proper OPML. But since RSSOwl imported the XMl file, I exported the feed list as OPML, which would be imported into Liferea or any other application.

An ARM comparison: Raspberry Pi vs OpenRD Client

Bellow there’s a comparison between Raspberry Pi (Model B) and OpenRD Client, two low-power ARM SoC (System on a Chip), running Linux (Rasbian and Fedora respectively). I used the EEMBC CoreMark benchmark with default settings for 100000, 1000000 and 2000000 iterations. For each set, each device keep its performance with the same rate of iterations per second. The difference between the devices is at, an average level of, 520 iterations per second. That translates to 1.4x faster in favour of the OpenRD Client.

While OpenRD Client performs better, in terms of efficiency, Raspberry Pi seems to doing much better. In terms of CPU, Raspbeery Pi uses a 700MHz (with the possibility of setting it up to 1GHz) ARMv11 processor while OpenRD Client an older 1.2GHz Marvell Sheeva (ARMv5TE). ARMv11 supports an FPU unlike ARMv5 and that is one of the reasons that Raspberry Pi performs quite well despite its lower specifications. In terms of memory, Raspberry Pi uses 256MB DDR2 800MHz (newer models have 512MB RAM), in share with its relatively powerful GPU, while OpenRD Client uses 512MB DDR2 800MHz. OpenRD Client also provides Gigabit Ethernet as well as many more I/O interfaces. Also, OpenRD has preloaded OS, unlike Raspberry Pi that boots from an SD card. During this benchmark, Raspberry Pi was running Rasbian “Wheezy” (unofficial Debian port to armhf) while OpenRD Client Fedora 8.


(Raspberry Pi diagram – http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspi_Iso_Blue.png)


(OpenRD Client Hardware Block diagram – http://www.globalscaletechnologies.com/skins/skin_1/images/OpenRD-Client_back.PNG)

HFS+ on Linux

My MacBook Pro seems to have died. Its hard disk holds lots of data that have not been backed up anywhere else. The important data have been mostly backed up but latest changes haven’t been backed up. Other than that, I had to check the hard disk for bad sectors etc and since I don’t have another Mac to test it on I had to do it on my Fedora box. My system (Fedora 15) would automatically detect and mount the HFS+ hard disk on read only mode. It was also missing the fsck tool for HFS+ partitions. Getting the fsck tool for HFS+ required downloading and installing hfsplus-tools via yum.However, fsck.hfs will not allow you, except if you use the –force option, to scan the partition if it has journalling on, which is the case with HFS+ partitions by default.

But how would I turn off journalling when I don’t have a Mac system to attach my disk on? After a couple of minutes I came across a post on the Ubuntu forum which linked to this blog. The author has a C code that turns journalling off. A fixed version of this code can be found here. The compiled code results in an executable which gets as its only argument the partition that you want to get journalling off.

# gcc journalling_off.c -o journalling_off
# ./journalling_off /dev/sdg2

Next step was to perform the fsck check on the target disk

# fsck.hfs /dev/sdg2
** /dev/sdg2
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking multi-linked files.
** Checking Catalog hierarchy.
** Checking Extended Attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume OS X appears to be OK.

Disk looks OK. Next step is to mount it with read-write permissions:

# mount -t hfplus -o rw,user /dev/sdg2 /mnt/osx

Next issue encountered was the different UIDs between my account on the OS X system and that on the Linux system. Therefore, next step was to change the UIDs under the whole user directory on the OS X disk so I could access without problem with write permissions from my Linux box:

# find panoskrt/ -uid 501 -exec chown panoskrt {} \;