Launch Jack Audio Connection Kit daemon with realtime scheduling

Today, it is very simple to launch the Jack Audio Connection Kit daemon with realtime scheduling, with a no-root user.
When Jack Audio Connection Kit is installed, it adds specific "limit" to jackuser group, into Pluggable Authentication Modules (pam).
Cf. the /etc/security/limits.conf file.

So the only need is to add the user which must need to launch the Jack Audio Connection Kit daemon with realtime scheduling into the jackuser group:
/usr/sbin/usermod -G jackuser "username"

Then, use the -R option when launching Jack Audio Connection Kit daemon:
jackd -R ...

N.B.: those instructions have been performed (at least) under Fedora 8

Use MIDI software "soundfonts mapping"

This is a quick "how to", to use softwares installed like explained on this post:
- launch Jack Audio Connection Kit daemon with options according to your configuration (let's said you are using ALSA)
jackd -R -d alsa
The -R option is used for "real-time", I explain it into my next post.
- launch a fluidsynth GUI frontend
qsynth
- setup the wished soundfonts (there we're using the path of the fluid R3 soundfonts), setup->Soundfonts->Open and selects the path /usr/share/soundfonts/FluidR3_GM.SF2 (under Fedora 8),
- finally launch Rosegarden and play MIDI files or Rosegarden Studio of your choice
rosegarden
- you may need to update configuration of the MIDI devices, Studio->Manage MIDI devices.

N.B.: those instructions have been performed (at least) under Fedora 8

Setup MIDI software "soundfonts mapping" (instead of hardware)

In this post, I've (quickly) explained how to set up environment to play MIDI file, loading soundfonts into wavetable of the sound card.
Nevertheless, the soundfonts which can be loaded into the sound card is obviously limited to available memory and so compromise must be done between quality and size.

Instead of this, it is possible to use software "soundfonts mapping". Today, there is lots of very powerful and mature softwares although all must be set up with caution to avoid latency issue.
There is various interesting explanations on the subject, for instance Planet CCRMA at home, and Linux MAO.

This is the software which an be used (prefixed by corresponding package name under Fedora):
- jack (Jack Audio Connection Kit): a low-latency audio server,
- qjackctl: a simple application to control the JACK sound server,
- fluidsynth: a real-time software synthesizer based on the SoundFont 2 specifications,
- qsynth: a fluidsynth GUI front-end application,
- fluid-soundfont-R3: fluid R3 soundfonts of good quality,
- rosegarden4: a professional audio and MIDI sequencer, score editor, and general purpose music composition and editing environment.

N.B.: those instructions have been performed (at least) under Fedora 8

Prepare Fedora environment to become an audio plateform

After some search of interesting tools to play midi musics (with external devices) under GNU/Linux, I finally find an unbelievable project: Planet CCRMA at home.
They provide all needed packages for updating an environment "to transform it into an audio workstation with a low-latency kernel".

There is rich installation information on the official site.

My first aim is to discover the astonishing features of Rosegarden.
To get it fully installed, I have had to install some additional packages XML::Twig and LilyPond:
yum install perl-XML-Twig lilypond

Currently the real-time kernel does not boot on my computer, I'll surely post information about this later ...

N.B.: those instructions have been performed (at least) under Fedora 8

Play MIDI under GNU/Linux with ALSA

There is lots of articles on the subject but it is not so trivial to get needed information to use ALSA tools to play MIDI files.

This is some quick information:
- the first is obviously to have a working ALSA installation,
- if you have several sound cards, ensure the default is well the wanted one (for instance using system-config-soundcard under Fedora),
- then it is important to ensure not having mute channel(s), you can use alsamixer for this,
- then ensure to have a way to load soundfonts into the wavetable of the sound card; for instance of sound card managed AWE32/Emu10k1 sound driver, you can install the awesfx package
yum install awesfx
- get a soundfonts to load, for instance this one,
- at any moment, to check if there is a loaded soundfonts:
cat /proc/asound/card?/wavetableD?
- you can clear currently loaded soundfounts but you want to keep it:
/bin/asfxload -i
- then load it:
/bin/asfxload "soundfonts file path"
- find the "addresses" into the "/proc/asound/card?/wavetableD?" file (for instance: 17:0 17:1 17:2 17:3),
- finally test installation using aplaymidi to play a MIDI file
aplaymidi -p "addresses"* "MIDI file path"
* addresses must be coma separated, 17:0,17:1,17:2,17:3 for instance.

Define the different installed packages between GNU/Linux installations

Let's call one installation local, and the other remote.
On the first one, use rpm to get the list of installed packages:
rpm -qa --qf "%{NAME}.%{ARCH}\n" |sort > /tmp/localInstallationInstalledPackages

Idem, on the second one:
rpm -qa --qf "%{NAME}.%{ARCH}\n" |sort > /tmp/remoteInstallationInstalledPackages

Then, get the differences between each list using diff.

To see the package installed on the local installation, but not on the remote one:
diff /tmp/localInstallationInstalledPackages /tmp/remoteInstallationInstalledPackages |grep "^<"

To see the package installed on the remote installation, but not on the local one:
diff /tmp/localInstallationInstalledPackages /tmp/remoteInstallationInstalledPackages |grep "^>"

In the two cases, to get a list of regarded packages on one line, use the following instructions.
For instance, for the local installation:
diff /tmp/localInstallationInstalledPackages /tmp/remoteInstallationInstalledPackages |grep "^<" |awk '{print $2}' |sed -e 's/$/ /' |tr -d '\n'

Then, you can use this list to [un]install corresponding packages on local or remote installation.

In addition to this post, those instructions allow to get exactly the same installed packages between GNU/Linux installations.

Install the same packages between two GNU/Linux installation, using yum

There is some cases where it is interesting to ensure having the same installed packages between two GNU/Linux installation.
Those installations must be of same architecture and be as near as possible (ideally the same version), otherwise it is obvious it won't work. In addition, it is needed to have the same rpm packages sources (for instance the same repositories if using yum).
For instance, it gives the ability to create a virtual machine with almost the same configuration, and then to perform lots of "tests" (upgradibility ...) without risk (but the one to get a "dead virtual machine") before performing the same instructions on the "original" installation.
Personally, I've used this ability to test upgradibility between Fedora 8 and Fedora 9.
To get the list of installed packages of an installation (including the architecture, which is particularly important there):
rpm -qa --qf "%{NAME}.%{ARCH} " > /tmp/allPackagesList

Then copy the file to the other installation.

Finally, use yum (or something else), to install all those packages (for instance, under GNU/Bash):
yum install $( cat /tmp/allPackagesList )

Such a way, all the packages installed on the first installation, will be installed on the other one.
Nevertheless, there may be other packages already installed on the second one, so the installed packages would not be exactly the same.
I'll write another post to explain how to remove such packages.

Personal Knowledge Base

I've recently used Trac to create a little personal Knowledge Base.
The only aim of this Knowledge Base is to centralize access to various quick information corresponding to specific computer science issues/situations.

Initially, I've set up this system for personal purposes.
Nevertheless, if you find current tickets (Knowledge Base elements) interesting and you wish to add some yourself, send me an email to admin[dot] knowledgeBase[at]bsquare[dot]no-ip[dot]org.

There is currently very few tickets (lack of time), but as soon as possible, I'll add more.

Get sound working with plugins for Firefox or Opera 9 under Fedora 8 (i386 and x86_64)

In addition to plug-ins installation (see this post), it is needed to ensure having an installed soundwrapper to get sound working under a Web Browser.
Whatever the architecture of the OS, it seems absolutely needed to have a i386 installed soundwrapper.
For instance, install the arts (KDE) soundwrapper:
yum install arts.i386

Install multimedia plugins for Opera 9 under Fedora 8 (i386 and x86_64)

There should be no problem to get multimedia plug-ins installed for Opera 9 under Fedora with a "full" i386 or x86_64 architecture installation.
In some cases, this post may help (Opera being "Mozilla compatible" as Firefox) with installation having i386 and x86_64 components.
Nevertheless, other situations may still need additional instructions to be performed.

It was my case with my installation: Opera 9.27 (i386), under a Fedora 8 x86_64 installation.
In particular, the gecko-mediaplayer package (replacing the mplayerplug-in one) was available only in x86_64 architecture. The nspluginwrapper method does not seem to work with Opera, so a i386 version of gecko-mediaplayer package is needed.
This is quick way to get it installed:
- get a i386 version, for instance browsing the livna repository online, or using yumdownloader under a i386 installation,
- install it using yum (it will install all the needed dependencies)
yum localinstall "gecko-mediaplayer-XXX.rpm"
- the i386 plug-ins might be installed under /usr/lib/mozilla/plugins

To enable plug-ins into Opera, follow the usual way:
- Menu Tools->Preferences->Advanced->Content->Plug-in options->Change path
- add the /usr/lib/mozilla/plugins path (or equivalent)
- valid, and then click "Find new..." button.

Close and launch again Opera.
You may use the -debugplugin option to get debug information about plug-ins.

Finally, under Opera, take a look to the "opera:plugins" information page to check if plug-ins are available.

Install Opera 9 under Fedora 8 (i386 and x86_64)

Those instructions might be interesting for other configuration too (for instance Fedora 7 and prior).
The GNU/Linux Opera 9 package does not seem providing all needed dependencies information. Such a way, even if the rpm is well installed, there might be trouble to launch Opera.

To begin, to install Opera:
- download the rpm of the wished version, Opera 9.27 being currently the latest stable one;
- install it with yum to get the maximum (but not all) needed packages installed too:
yum --nogpgcheck localinstall "opera-XXX.rpm"
- ensure to have qt package installed (i386 for v9.27 and prior; x86_64 might be enough for newer version)
- ensure to have a up to date Java installation to benefit from the maximum functionalities (again, i386 for v9.27 and prior; x86_64 might be enough for newer version)
- it might be needed to update the LD_LIBRARY_PATH to specify where to find some libraries: libqt-mt.so (qt), libjvm.so and libawt.so (Java):
For instance, if you have installed the i386 JDK 6u6 under /usr/share/java/jdk1.6.0_06.i386/
export LD_LIBRARY_PATH=/usr/lib64:/usr/lib/qt-3.3/:/usr/share/java/jdk1.6.0_06.i386/jre/lib/i386/client/:/usr/share/java/jdk1.6.0_06.i386/jre/lib/i386/

Compile VMwareTools on Linux kernel 2.6.22

To compile the vmhgfs VMwareTools on Linux kernel 2.6.22, it is needed to patch the source code, like explained there, from a tar.gz installation.
The same fix works from rpm installation, although the VMwareTools source code directory may be different (/usr/lib/vmware-tools/modules/source for me):
- move to /usr/lib/vmware-tools/modules/source/
- untar vmhgfs.tar and backup it
- then follow the same instructions:
"Now edit vmhgfs/driver.c and change lines 44 and 45 from
#define INODE_SET_II_P(inode, info) do { (inode)->u.generic_ip = (info); } while (0)
#define INODE_GET_II_P(inode) ((HgfsInodeInfo *)(inode)->u.generic_ip)
to
#define INODE_SET_II_P(inode, info) do { (inode)->i_private = (info); } while (0)
#define INODE_GET_II_P(inode) ((HgfsInodeInfo *)(inode)->i_private)

Also, remove line 763: inode->i_blksize = HGFS_BLOCKSIZE;
"
- create a new vmhgfs.tar with patched source code
- the compilation can now be fully performed -> launch /usr/bin/vmware-config-tools.pl again

Upgrade manually an installed perl module

When an application requires a minimum perl module version which is not provided by installed RPM, it can be upgraded manually.
For instance, it is the case of amavis (see create a full and secured emails server), when upgrading some perl rpm packages (perl-CPAN for instance).

To upgrade CPAN perl module manually, opens a perl shell:
perl -MCPAN -e shell

Then request the "install" of the newest available perl module version. For instance:
install File::Temp

Define the current version of a perl module

To get the current version of an installed perl module, the following command can be used:
perl -le 'use MODULE_NAME; print MODULE_NAME->VERSION'
With MODULE_NAME the name of the wished perl module.

For instance with File::Temp it gives:
perl -le 'use File::Temp; print File::Temp->VERSION'

Get the list of gcc defined macro after preprocessing

It various situation, it is very useful to get the list of all defined maco after gcc preprocessing.
Particularly when porting C/C++ source code to another OS/Architecture to know what macro to use to identify it.

A simple way is to use gcc with the following options:
-E to end after preprocessing step,
-dM to print all defined macros.

For instance to known the "default" macros, use those options with a simple source code file "test.c" defining a main function:
gcc -E -dM test.c

Fix empty /var/log/boot.log file issue

The local7 facility is used to write into the /var/log/boot.log file.
But since the Fedora core 4, the system has been disabled waiting for a new generation system which does not seem to be available yet (see this bug report and this one)

A quick way to fix the empty /var/log/boot.log file, is to edit the /etc/rc.d/init.d/functions file.
Into the success, failure, passed and warning functions, you can add a line like the following, just before the return instruction:
/usr/bin/logger -p local7.info "$1"

It works but each time the initscripts package is updated, it is needed to edit the file ...

Make Red Hat Graphical Boot detailed

There is unfortunately no configuration file allowing to switch on/off the details of Red Hat Graphical Boot.
Anyway, for it to be detailed, the /etc/rc.d/init.d/functions can be edited:
- simply add --details=yes into the update_boot_stage function on the line using the /usr/bin/rhgb-client.

It works but each time the initscripts package is updated, it is needed to edit the file ...

Updating courier-imap configuration

By default, the courier-imap creates pop3 (110), pop3s (995), imap (143) and imaps (993) servers.
Generally, they are not all needed, and for obvious security reasons, it is better to not start useless servers.

Under GNU/Linux Fedora, the corresponding configuration files, which are under /usr/lib/courier-imap/etc/, are respectively pop3d, pop3d-ssl, imapd and imapd-ssl.
Into each, there is a variable XXXSTART (with XXX corresponding to POP3D, POP3DSSL, IMAPD or IMAPDSSL) which can be YES or NO.

To not start such a server, it is enough to replace corresponding YES by NO.

Finally, restart the courier-imap service.

Upgrade GNU/Linux Fedora from core 6 to 7, then 8 (with yum)

To upgrade GNU/Linux Fedora from core 6 to 7, then 8, there is no [really] problem today.
It was not the case when I've tried it as soon as Fedora 7 was available, but I've successfully performed such an upgrade without difficulties some days ago.

The principle is globally the same when upgrading from Fedora core N to Fedora core N+1 (see this post), or from Fedora 7 to Fedora 8 (see this post).
In addition, the recommendations of Fedora project have greatly evolved and seem now complete.

This is some additional instructions in case you have specific issues (like I had):
Update your /etc/fstab file:
It is very important to use label (LABEL=myLabel) to identity your device instead of path (/dev/xxx). The identification has changed from Fedora core 6 to Fedora 7, generally from /dev/hdX to /dev/sdY BUT there is absolutely no certainties that X and Y will equal between versions.

Using labels ensure your mount points are always the same.
Particularly it ensures your root partition (/) will be the good, and your computer will well boot after upgrade.
To update the label of a device, you can use the tune2fs command.

Upgrade from Fedora core 6 to Fedora 7:
- do not forget to clean all the yum metadata with yum clean all,
- upgrade the Fedora release:
rpm -Uhv ftp://download.fedora.redhat.com/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/fedora-release*.noarch.rpm
- upgrade your repository, for instance for livna:
rpm -Uvh http://rpm.livna.org/livna-release-7.rpm
- remove and reinstall authconfig to avoid specific issue.

Upgrade from Fedora 7 to Fedora 8:
- do not forget to clean all the yum metadata with yum clean all,
- upgrade the Fedora release:
rpm -Uvh http://mirror.anl.gov/pub/fedora/linux/releases/8/Everything/i386/os/Packages/fedora-release-*.noarch.rpm
- upgrade your repository, for instance for livna:
rpm -Uvh http://rpm.livna.org/livna-release-8.rpm

Ensure there is no dependencies problem like explained into this post.

Then, you should perform a great configuration files merging campaign to ensure having the up to date functionalities while keeping your own specific configuration (globally the XXX.conf and XXX.conf.rpmnew files).

Clean useless packages under 64bits GNU/Linux

It seems there is some dependency "issues" when installing a 64bits GNU/Linux. It is, for instance, the case under Fedora.
Although the architecture of the installed OS is 64bits, there is some i386 or i686 installed packages.
Some are needed, but lots might be removed.

To begin, to get a sorted list of such potential packages, you can use:
rpm -qa --qf "%{NAME}.%{ARCH}\n" |grep -v x86_64 |grep -v noarch |grep -v "(none)" |sort

Then, you can remove all packages you are sure you do not need, but be careful with the dependencies.
To make it quicker, you can request the remove of package(s) you know it is needed by lots of others (like some libraries).

After all of this, ensure there is no dependencies problem. For instance, with yum utilities:
- ensure the database is up to date with rpm --rebuilddb,
- check if there is problem with package-cleanup --problems.

Finally, to complete the cleaning, you can use the package-cleanup --leaves and ensure you need all those "independent" package(s), else remove them.

Personally, I have removed about 150 packages like this.
For information, there is some i386/i686 packages which are needed by x86_64 ones.
It was the case for me with compat-libstdc++-33.i386, libgcc.i386 and glibc.i686.

Get 32bits firefox plugins available under 64bits system

There is various article about this, but I have not found all needed information into only one.
This is a quick method to get 32bits firefox plugins available under 64bits system:
- install wished 64bits plugins,
- install 32bits plugins if there is no 64bits version (like for macromedia flash),
- install nspluginwrapper 64 and 32 bits (important to have the two versions),
- ensures 32bits plugins are available under /usr/lib/mozilla/plugins (or create symbolic links),
- ensures 64bits plugins are available under /usr/lib64/mozilla/plugins (or create symbolic links),
- according to your OS, it may then be enough to restart firefox (like under Fedora 8),
- else, use the mozilla-plugin-config -i command.

It is possible to not create symbolic link, and to specify path of corresponding .so file with the mozilla-plugin-config -i.

Each wrapped plugins should be under
/usr/lib64/mozilla/plugins-wrapped (or maybe equivalent). If it is not the case, you can use the -v option while using mozilla-plugin-config.

Finally, under Firefox, you should see all available plugins under "about:plugins".

Reinstall packages from another source/Vendor without broking dependencies

There is various situations leading to the wish to reinstall packages from another source/Vendor without broking dependencies.
It is not so easy when continuity of services is an important need.
To avoid difficulties, try to make it with iterative manner, "package set" by "package set".

This is the steps which can be followed for each iteration:
- define with the greatest precision the packages which must be updated (this post can help for this),
- define the dependencies which might be broken while removing regarded packages (this post can help for this),
- ensure there is another source for each package which must be reinstalled, for instance with yum:
yum search packageName1 ... packageNameN
- with great caution, remove the packages regardless to dependencies:
rpm -e packageName1 ... packageNameN --nodeps
- finally, install the new version from wanted source, for instance with yum:
yum --disablerepo=unwantedSource install packageName1 ... packageNameN
- ensure there is no problem, particularly about dependencies:
package-cleanup --problems

As final check, restart the services which may have been affected to ensure there is no warning/error.

Split a file into several ones with dd

To split quickly a file in several ones (for greatest management, better legibility ...), the dd command can be used.

To create the /path/to/my/destination/file with the first N MBytes of the /path/to/my/source/file:
dd if=/path/to/my/source/file of=/path/to/my/destination/file bs=1048576 count=N

Manage services under Solaris

A simple refresh of what can be done with svcs and svcadm tools.

Get list of all services:
svcs

Add a service:
To begin, a manifest file is needed to define the service (some information there).
Then, it is needed to ensure it is valid:
xmllint --valid /path/to/my/service/manifest/file

Finally, the service can be add:
svccfg import /path/to/my/service/manifest/file

Activate a service (which has been priorly added):
svcadm enable * serviceName
The -s option can be used to get focus only after the service is fully activated (or failed).

Disable a service:
svcadm disable * serviceName
The -s option can be used to get focus only after the service has been disabled.

Put a service under maintenance:
svcadm mark * serviceName

Remove the "maintenance" status of a service:
svcadm clear * serviceName

Update the configuration of a service:
svcadm refresh * serviceName

Get the current status of a service:
svcs -x serviceName stop

Manage services under GNU/Linux distributions providing service and chkconfig

A simple refresh of what can be done with service and chkconfig tools.

Get list of all services and their state for each runlevel (including inet and/or xinet if available):
chkconfig --list

Get state for each runlevel of one service (including inet and/or xinet if available):
chkconfig --list serviceName

Remove a service:
chkconfig --del serviceName

Add a service (with state for each runlevel defined automatically according to the service definition file):
chkconfig --add serviceName

Add a service with specific state for some runlevels:
chkconfig --level * serviceName on|off**
* one or several runlevel(s) specified without separator
** only "on" as sense there (to add/activate the service)

Define the state for some runlevels of an installed service:
chkconfig --level * serviceName on|off*
* "on" to "activate" the service, "off" otherwise

Get the current status of all services:
service --status-all

Get the current status of a service:
service serviceName status

Start a service:
service serviceName start

Stop a service:
service serviceName stop

Restart a service:
service serviceName restart

Request DEB packages ("Debian-like" GNU/Linux distribution)

A simple refresh of what can be done with dpkg tool.

All those commands query installed packages.

Get the list of packages:
dpkg -l

Get the list of packages matching a specific pattern:
dpkg -l pattern
For instance for libraries: dpkg -l lib*

General information about a package:
dpkg -s myPackageName[-myCompletePackageVersion]

Get the list of files of a package:
dpkg -L myPackageName

Get the package providing a specific file:
dpkg -S myFilePathOrPattern*
*: absolute path or pattern

To get the general information of the package providing a specific file (under GNU/Bash) with only one command line:
dpkg -s $( dpkg -S myFilePath |awk '{print $1}' |sed -e 's/://g;' )

Request RPM packages ("Redhat-like" GNU/Linux distribution)

Request RPM packages ("Redhat-like" GNU/Linux distribution)
A simple refresh of what can be done with rpm tool.

To begin, the -q option allow to select the RPM packages to request.
The -a option allow to select all (potentially with a pattern to match).
Name, pattern and even version can be specified for greatest precision in selection.

All those commands query installed packages.

Get the list of packages:
rpm -qa

Get the list of packages matching a specific pattern:
rpm -qa pattern
For instance for X libraries: rpm -qa lib*X*

General information about a package:
rpm -qi myPackageName[-myCompletePackageVersion]
For instance, for a specific kernel: rpm -qi kernel-2.6.20-1.2962.fc6

Get the list of files of a package:
rpm -ql myPackageName[-myCompletePackageVersion]

Get ChangeLog of a package:
rpm -q --changelog myPackageName[-myCompletePackageVersion]

Get the list of packages needed by another package:
rpm -qR myPackageName[-myCompletePackageVersion]

Get the list of what provides a package:
rpm -q --provides myPackageName[-myCompletePackageVersion]

Get the list of packages providing a specific functionality:
rpm -q --whatprovides functionalityName
For instance, for the perl functionality "Authen::SASL": rpm -q --whatprovides "perl(Authen::SASL)"

Get the package providing a specific file:
rpm -qf myFilePath*
*: the path can be relative to current directory or absolute

To get the general information of the package providing a specific file (under GNU/Bash) with only one command line:
rpm -qi $( rpm -q --file myFilePath )

Define what is the installed GNU/Linux distribution

The "release" part of the Linux Standard Base (LSB) allow answering this question.

Tips:
- to install it under GNU/Linux Fedora, use yum install redhat-lsb
- to install it under GNU/Linux Debian, use apt-get install lsb-release

Then, simply use the command lsb_release -i.

This is output instances:
- under GNU/Linux Fedora, it answers "Distributor ID: Fedora"
- under GNU/Linux Debian, it answers "Distributor ID: Debian"

Define installed packages of specific Vendor

When lots of things are installed on a computer, it is sometimes difficult to define what are the installed packages of a specific vendor.
This is a little command allowing to get such Information :
rpm -qa --qf "%-30{NAME}\t%{VENDOR}\n" |grep -i VENDOR_NAME

VENDOR_NAME must be replaced by what you want ("Red Hat" for instance).

The opposite can be done. To define what are the installed packages which are not provided by a specific vendor :
rpm -qa --qf "%-30{NAME}\t%{VENDOR}\n" |grep -v VENDOR_NAME