Last week, I set up an overlay to store and share some of my ebuilds. The overlay is hosted on Launchpad so you will need Bazaar to access it. Right now it has ebuilds for Gambas, collectd and PyICU (used in Chandler) and I plan on adding more in the future.
To start using the overlay, download the overlay.xml file from the overlay's web-based interface and add it to the overlays line in /etc/layman/layman.cfg. After that you can use layman to add it to your list and use it.
While considering new partitioning schemes and filesystem choices for future installs and reinstalls, I realized that I had almost no idea what kind of files were on my system. I needed to see histograms of file sizes in particular directories in order to make better decisions for partitioning, filesystem selection and filesystem tuning.
I started playing with the du command to try and get some data and after a while I came up with the following:find . -type f -execdir du --apparent-size --block-size=512 '{}' \; | grep -o ^[0-9]* | sort -n | uniq -c
This series of commands produced the data I was looking for and I graphed it using OpenOffice Calc. Here is a summary of what I got for the directories of Portage. As expected, there were "lots of small files."
First, the Portage tree (no /distfiles here):
You can clearly see the portion of files less than 2k compared to the rest. There are a lot of them, but they do not take up the majority of the space.
Then the Portage cache:
Lots of 512b+ to 1k files here, represented by the yellow region.
Finally, the Portage installed packages database:
Lots of sub 512b files, but they do not take up a lot of the space.
In retrospect, I needed to use something better than OpenOffice to graph the data and I will update this post if I get to it. Since the histograms were quite skewed as you can see from the results above, here are some maps generated by FSview to give you a different view of the directories:
From left to right: the Portage tree, the Portage cache and the Portage installed packages database
A time server provides a convenient way to set the correct time, and maintain the accuracy of the internal clock on your computer. This tutorial explains how to set up a time server for a local network and eliminate the need for computers to query external time servers directly. For this tutorial, the NTP server software provided by Internet Systems Consortium, Inc. (ISC) will be used. An alternative is the OpenNTPD software, but this tutorial will not cover it.
On Gentoo, the ntp package contains both the NTP server (ntpd) and client utilities. It needs to be installed on both your time server and every computer that will synchronize to it.
To install ntp on Gentoo, simply emerge it:
# emerge ntp
You may want to verify that the caps USE flag is set before you begin the emerge so that the ntpd daemon will use Linux capabilities. Keep in mind that Linux capabilities also have to be enabled in your kernel.
Ubuntu Feisty (7.04) and newer versions also provide a single ntp package:
$ sudo apt-get install ntp
But Ubuntu Dapper (6.06LTS) and Edgy (6.10), have separate packages for the client utilities
$ sudo apt-get install ntp
and the server.
$ sudo apt-get install ntp-server
Check your distribution's package manager to make sure you install the correct package(s).
The server in this tutorial will be setup as a standalone server. It will provide time service to one or more local networks and synchronize its system clock to one or more external time servers. The NTP documentation discusses additional operating modes, like peering, and more complicated mission-critical setups, but these topics are beyond the scope of this tutorial.
The main configuration file for the ntpd daemon is ntp.conf. It is usually installed in /etc, but this may be different on your distribution. The following steps outline the configuration process for ntpd as a server:
Open your ntp.conf file with a text editor. The default ntp.conf file should have several commands with locations that may be specific to your system.
Look for a line containing the driftfile command. This command specifies a file that is used by ntpd to improve its timekeeping performance. It is important that this line is kept enabled. If your distribution's package does not have a designated driftfile, you should read its documentation, find an appropriate location to store the driftfile, and specify one.
Look for a line containing the logfile command. This command specifies a file where messages are logged, as an alternative to syslog(3). You may wish to comment it out so that messages are logged by syslog(3) and the log is rotated automatically.
/etc/ntp.conf
...
driftfile /var/lib/ntp/ntp.drift
# logfile /var/log/ntp.log
...
Specify one or more server commands. The server command instructs ntpd to periodically query an external time server and synchronize the system clock. For a list of public time servers check the ntp.org website or search the Internet for time servers provided by institutions in your geographic region. For example, synchronizing to a time server provided by the National Institute of Standards and Technology's (NIST) Time and Frequency Division in the United States is specified with the following command:
/etc/ntp.conf
...
server time.nist.gov
...
Usually you should specify more than one server for synchronization, in case of network problems outside of your network. However, ntpd will only use up to three of the specified servers at a time to keep the system clock synchronized.
(Optional) Use the minpoll and maxpoll options with the server command. These options define how often your server queries the external time server(s). The defaults are 6 for minpoll and 10 for maxpoll. The polling period for both minpoll and maxpoll is 2x seconds where x is the number specified for the option. You should manually set these to higher values than the defaults since there is no need to poll the external time server(s) that often. The range of the two options is 4 - 17.
/etc/ntp.conf
...
server time.nist.gov minpoll 7 maxpoll 11
...
Use the restrict command to define the level of access to your time server. By default, with no restrict commands, the server has no restrictions. You may want to read the ntp.conf man page for more information on the available options.
The default (0.0.0.0 mask 0.0.0.0 or [::/128]) restrictions should usually be very limiting, like the following:
/etc/ntp.conf
...
restrict -4 default noquery nomodify nopeer notrap
restrict -6 default ignore
...
The "-4" and "-6" after the restrict keyword are address qualifiers that determine whether the following should be resolved to an IPv4 or IPv6 address respectively.
After the default restrictions are specified, lesser restrictions need to be defined for your local subnets. The following example illustrates restrictions for the example, local, IPv4 subnets 192.168.0.0/24 and 192.168.1.0/24.
/etc/ntp.conf
...
restrict 127.0.0.1 nomodify nopeer notrap
restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap
restrict 192.168.1.0 mask 255.255.255.0 nomodify nopeer notrap
...
(Optional) The NTP server can announce its presence on the network by both broadcasting and multicasting. Multicasting is covered in the ntp.conf man page and will not be covered here. To enable the server to announce its presence through broadcasts, use the broadcast command and specify a broadcast address.
/etc/ntp.conf
...
broadcast 192.168.1.255 minpoll 10
...
The minpoll option is not mandatory. It defines the broadcast frequency in the same way as it did for the server keyword. You should use it and set it to a reasonable value to reduce broadcast traffic on your targeted broadcast address.
The ntpd daemon should now be configured and can be started. This is what a complete ntp.conf file might look like:
/etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
#logfile /var/log/ntp.log
server time.nist.gov minpoll 6 maxpoll 10
server time-a.nist.gov minpoll 6 maxpoll 10
server time-b.nist.gov minpoll 6 maxpoll 10
broadcast 192.168.1.255 minpoll 10
restrict -4 default noquery nomodify nopeer notrap
restrict -6 default ignore
restrict 127.0.0.1 nomodify nopeer notrap
restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap
restrict 192.168.1.0 mask 255.255.255.0 nomodify nopeer notrap
There are more than a couple of ways to configure ntpd as a simple client. Three of them are explained in the following sections.
On Linux, the DHCP client has the ability to overwrite the ntp.conf file with settings that will allow a computer to synchronize to NTP servers that a DHCP server advertises. If this feature is disabled on your distribution, look at the documentation for your DHCP client to try to enable it.
To advertise NTP servers with your DHCP server, add the ntp-servers option to the server's dhcpd.conf configuration file.
/etc/dhcp/dhcpd.conf
...
option ntp-servers 192.168.0.1;
...
Specify the domain name or IP address of your local time server with the server command. For example, if 192.168.0.254 is the IP address of your NTP server:
/etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
#logfile /var/log/ntp.log
server 192.168.0.254
restrict -4 default ignore
restrict -6 default ignore
restrict 127.0.0.1 nomodify nopeer notrap
restrict 192.168.0.254 nomodify nopeer notrap
You need to make sure that the DHCP client will not overwrite your ntp.conf file. On Gentoo, you can disable this overwrite by adding nontp to the DHCP configuration options in /etc/conf.d/net, as shown below.
/etc/conf.d/net
...
dhcp_eth0="nontp"
...
To enable your ntpd daemon to receive broadcasts from a local time server, you need to add the following lines to your ntp.conf file. Also you have to remove the nopeer option from the default restriction, otherwise ntpd will not open a new client connection to the NTP server when it receives a broadcast packet.
/etc/ntp.conf
...
disable auth
broadcastclient
restrict -4 default noquery nomodify notrap
...
Here is what a complete configuration might look like:
/etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
#logfile /var/log/ntp.log
disable auth
broadcastclient
restrict -4 default noquery nomodify notrap
restrict -6 default ignore
restrict 127.0.0.1 nomodify nopeer notrap
On Gentoo, you may want to enable this option to "set the Hardware Clock to the current System Time during shutdown."
File: /etc/conf.d/clock
...
# If you want to set the Hardware Clock to the current System Time
# during shutdown, then say "yes" here.
CLOCK_SYSTOHC="yes"
...
On Gentoo, simply start the service.
# /etc/init.d/ntpd start
You also want to add it to your default runlevel so it will always start automatically at boot.
# rc-update add ntpd default
The time server/client will take some time to synchronize to its external provider. You can check this synchronization process with the ntpq command. Here is an example of what the output will look like on a working server:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+india.colorado. .ACTS. 1 u 357 68m 377 46.433 5.071 0.152
*time-B.timefreq .ACTS. 1 u 585 68m 377 42.934 1.160 8.319
+time.nist.gov .ACTS. 1 u 396 68m 377 49.633 -0.656 1.736
The asterisk (*) in front of "time-B.timefreq" indicates that the server is synchronized and is providing time service.
If your server is broadcasting to a particular subnet, the result of the ntpq command will have an additional like similar to the following:
192.168.1.255 .BCST. 16 u - 256 0 0.000 0.000 0.001
I have been looking for an effective way to synchronize files across machines for quite some time. I researched online and found quite a few programs that synchronize files. However, no one program was overwhelmingly better than the rest and had the features I was looking for. I really needed to implement something, so last week I decided to see what I can do anything with rsync. After about a day, I came up with a simple shell script that worked for me. It is not glamorous, but it gets the job done. Here is an explanation of how you can set up something similar.
The image above illustrates an example computing environment that will be used in this post. This environment can be expanded, but for the simple shell script to work, the following items are necessary.
The Sync Server is the main synchronization point. The clients (Laptop, Home and Work Desktop) always synchronize their data to it, and not to each other.
SSH is already configured to provide the necessary level of security for the data you are synchronizing. The proper configuration of the SSH server and clients is beyond the scope of this post.
The clients must use the same top-level synchronization directory. The Sync Server's top-level synchronization directory can differ from the clients'.
In this example, the following directory structure will be used to store the synchronizable data. Both the clients and the Sync Server use the same top-level synchronization directory.
/sync/ - the top-level synchronization directory
/sync/mydocs/ - directory for personal documents
/sync/apps/ - directory for application data
/sync/apps/bash/ - directory that holds the synchronization shell script (IMPORTANT)
/sync/apps/ffox/ - copy of your firefox profile, modify your ~/.mozilla/firefox/profiles.ini to point here or use a symlink
/sync/data/ - directory containing other data
/sync/otherdata/ - directory containing data that we do not want to synchronize
If you have an user account on a restricted server and want to use it as the Sync Server, simply alter your paths to use your home directory.
~yourlogin/sync/
~yourlogin/sync/mydocs/
~yourlogin/sync/apps/
~yourlogin/sync/apps/bash/
~yourlogin/sync/apps/ffox/
~yourlogin/sync/data/
Create the top-level synchronization directory on all clients and the Sync Server. Set proper permisions and ownership as appropriate. The permissions of the files and directories are preserved during synchronization.
$ mkdir /syncOn one of your clients, create the directory that will store the shell script. In this example, that directory is /sync/apps/bash/.
$ mkdir /sync/apps
$ mkdir /sync/apps/bashCreate the following file. Modify the highlighted portions to your specific configuration.
/sync/apps/bash/bashrc
sync_rsync_options='-auv --exclude-from=/sync/apps/bash/sync-exclude'
sync_directory_up='/sync/{mydocs,apps,data} sync-server.dns:/sync/'
sync_directory_down='sync-server.dns:/sync/{mydocs,apps,data} /sync/'
alias sync-up-pretend="rsync -n --delete-delay --delete-excluded ${sync_rsync_options} ${sync_directory_up}"
alias sync-up-full="rsync --delete-delay --delete-excluded ${sync_rsync_options} ${sync_directory_up}"
alias sync-up-update="rsync --delete-excluded ${sync_rsync_options} ${sync_directory_up}"
alias sync-down-pretend="rsync -On --delete-delay ${sync_rsync_options} ${sync_directory_down}"
alias sync-down-full="rsync -O --delete-delay ${sync_rsync_options} ${sync_directory_down}"
alias sync-down-update="rsync -O ${sync_rsync_options} ${sync_directory_down}"
unset sync_rsync_options sync_directory_up sync_directory_down
This file provides you with six simple command alliases to do synchronization. Those will be explained later in the Usage section.
Create an exclude pattern file. Its basic usage it to prevent temporary files and cached data from being synchronized and wasting bandwith and storage. If you want complete synchronization, leave the file blank. Here is an example file:
/sync/apps/bash/sync-exclude
#General excludes
*~
#Mozilla Firefox
Cache/
XUL.mfaslCopy the shell script folder to every client.
Add the following line to the bottom of your .bashrc file.
~yourlogin/.bashrc
...
source /sync/apps/bash/bashrc
This will make the new synchronization command alliases available in all future bash sessions. You can run the above line as a command and the new alliases will be available immediatelly. Now you are ready to synchronize your data!
Move directories and files under the top-level synchronization directory and create symlinks to data that needs to appear somewhere else.
sync-up-full
Uploads all newly modified files to the Sync Server and deletes all files that are no longer present on the client from the Sync Server. CAUTION! It may delete important files from the Sync Server. If these files exist on other clients, a sync-up-full from one of those clients will restore them. Use with care.
sync-down-full
Downloads all new newly modified files from the Sync Server to the client and deletes all files no longeer present on the Sync Server from the client. CAUTION! It may delete important files that have not yet been synchronized to the Sync Server with sync-up-update.
sync-up-update
Uploads all newly modified files to the Sync Server.
sync-down-full
Downloads all new newly modified files from the Sync Server.
sync-up-pretend, sync-down-pretent
These commands will give you an overview of what will happen if you run sync-up-full or sync-down-full. No files are modified.
While this is a very simple synchronization setup, so far it has worked well for me. It is still a work in progress. I encourage you to read the rsync manual. It explains in detail the exclude patterns and the source and target specification rules.
A couple of months ago I switched to using Gentoo Linux as my main operating system. My laptop, a Dell Inspiron 9100, has an infrared port, but I have never been able to use it for anything useful. I tried to set up LIRC (Linux Infrared Remote Control) in the past on other Linux distributions and even in Windows XP with WinLIRC, but had no success. It took a lot of reading and testing, but I finally have LIRC working. In this post, I describe how to set it up properly.
The Dell Inspiron 9100 has a SMSC IrCC controller chip. These chips are present in many other laptops and this guide may help you even if you do not own the same laptop as me. The IrCC chips support both IRDA and CIR (Comercial Infrared) standards.
Before installing any software, check which COMM port the infrared controller is assigned to. This setting is located in the BIOS, so reboot your laptop and locate it. Typically it is set to COMM2 and that is what I used. COMM2 also works with the IRDA driver, in case you may want to use that in the future. I tried using COMM1, but could not get it to work.
In order to receive remote control infrared signals in Linux, you need to install LIRC. In Gentoo, this involves emerging (installing) lirc or one of the higher level packages that depend on it. I personally use KDE so I would emerge kdelirc or the meta package kdeutils-meta with the lirc USE flag set.
Before you begin emerging, however, you need to set a couple of options in /etc/make.conf to properly install lirc. First, you need to define which devices you plan to use with lirc so the appropriate modules are build during the emerge process. This is controlled by the LIRC_DEVICES option in /etc/make.conf. You can set it to all and lirc will support all available devices. For our controller, only the SIR driver is needed, therefore:
/etc/make.conf
...
LIRC_DEVICES="sir"
...
is sufficient.
For this particular device, I also enabled both the hardware-carrier and transmitter USE flags.
/etc/make.conf
USE=" ... hardware-carrier transmitter ... "
I am not sure if they are necessary or useful, but I do not have time to test that given that I got it to work.
Now that these options are set, you can install lirc. In my configuration I set the lirc use flag and emerged kdeutils-meta.
/etc/make.conf
USE=" ... lirc ... "
# emerge kdeutils-meta
After the packages have been successfully emerged, the LIRC kernel module, lirc_sir, needs to be configured.
Beforehand, however, make sure that the IRDA kernel module, smsc_ircc2, does not load automatically. This is unlikely, but it may happen that it is properly configured and able to load automatically on its own. Check with this command:
$ lsmod | grep smsc
If smsc_ircc2 is present, you need to blacklist it to prevent if from loading automatically. The lirc_sir and smsc_ircc2 modules cannot be loaded at the same time. To blacklist a module, edit /etc/modprobe.d/blacklist and add the following line, usually at the bottom:
/etc/modprobe.d/blacklist
blacklist smsc-ircc2
After making sure that the IRDA module does not load, the LIRC module can be properly configured. Until recently I did not know about the modinfo command and I had no idea how to do this correctly. This command gives you information about the module and what options the module accepts. Here is an example output of the modinfo command on my lirc_sir module.
# modinfo lirc_sir
filename: /lib/modules/2.6.22-suspend2-r2/misc/lirc_sir.ko
license: GPL
author: Milan Pikula
description: Infrared receiver driver for SIR type serial ports
depends:
vermagic: 2.6.22-suspend2-r2 SMP mod_unload PENTIUM4
parm: io:I/O address base (0x3f8 or 0x2f8) (int)
parm: irq:Interrupt (4 or 3) (int)
parm: threshold:space detection threshold (3) (int)
parm: debug:Enable debugging messages (bool)
Look at the "parm:" lines. These are the options that the lirc_sir module accepts. These can be specified while running the modprobe command. In order to load the lirc_sir module properly, the top three parameters need to be specified. When using COMM2, the following settings worked and properly loaded the module:
# modprobe lirc_sir io=0x2f8 irq=3 threshold=5
The first two parameters are specific to COMM2. The threshold parameter I have not explored in detail. I tried two, three (the default), four and five. Four and five were the two that worked so I chose five. You can experiment with those. I did not notice any negative site effects.
When the module loads successfully, you can test it with the mode2 program (run it as root). Just start the program and try pressing some keys on the remote while facing the receiver. You should see lines like to following start to appear.
# mode2
...
space 630
pulse 275
space 363
pulse 515
pulse 514
space 1763
pulse 514
space 1765
pulse 513
space 1798
...
If the screen remains the same, then something is not correct. Verify the settings and maybe experiment with the threshold parameter. To terminate the program, press Ctrl-C. Now the module is properly configured. To preserve the settings, add a new file (I named mine lirc-sir) to /etc/modprobe.d/ with the following text.
/etc/modprobe.d/lirc-sir
options lirc-sir io=0x2f8 irq=3 threshold=5
Then run modules-update to integrate the settings from this file.
# modules-update
Now, just typing modprobe lirc_sir will work. The options are looked up automatically. This module needs to be loaded before the lirc service is started. There are several ways to get this accomplished. The easy way it to just add lirc_sir to /etc/modules.autoload.d/kernel-2.6 or to the kernel-2.4 file if you do not use a 2.6 series kernel.
/etc/modules.autoload.d/kernel-2.6
...
lirc_sir
After the module is configured, the lirc daemon needs to be added to the start-up services. In Gentoo, the command is the following:
# rc-update add lircd default
In addition to lircd daemon, there is also a lircmd daemon. This daemon interprets button presses and sends them as mouse events to the system. I have not tried it yet, but it may make a nice follow-up post in the future.
From here you can follow the Configuring LIRC portion of the LIRC manual and everything should work.
In a follow up post I will demonstrate now to configure and use your remote in KDE.
Posts
