LVM stripe at most as large as the smallest physical volume in the volume group
It is certainly obvious but there was no mention of it in the LVM howto, and that made me feel the need to confirm it experimentally using lvcreate on an heterogeneous VG. So there : the size of an LVM stripe cannot be larger than the smallest physical volume (PV) in the volume group (VG).
Let me introduce some crepe goodness to the english-speaking world ! Considered by most non-French people as a rare delicacy, crepes are in fact a very easy and extremely cheap popular dish. The making and the eating of crepes are quite related to what practitionners of the american pancake are used to.
This is my own favorite interpretation – one of the many ways to prepare this folk dish. I tried many variations but settled on this one after much trial and error. This recipe is theoritically suited to salty fillings, but since I’m lazy I don’t prepare a separate bowl of sweet-specific mixture and eat this one with the sweet stuff just as well.
Ingredients :
All that makes twenty-one generous crepes – three crepes with filling feed an adult human nicely so the basic recipe should be good for seven guests. Multiply the quantities according to your guest’s apetites.
From separate ingredients to twenty-one crepes should take about thirty minutes.
Preparation : mix everything with enthusiasm. Other recipes recommand several hours of settling – mine does not : the liquid mash is ready immediately. How much simpler can it get ?
Cut a sliver of butter onto the hot pan, pour just enough mash so that by gently tilting the pan around you cover its whole surface with a thin continuous film. Then wait a few dozen seconds until the crepe unsticks naturally from the pan. Do not try to unstick it using a spatula as this will most likely result in a sticky messy heap of half-cooked crepe. Just wait until the crepe’s pan side is lightly brown and effortlessly turn it. When the second side is also lightly brown the crepe is ready. Stack it and prepare another one.
If Just In Time processes are more your thing, or if you are just an impatient glutton, set the filling on top of the crepe while the second side browns and eat your hot crepe right out of the pan.
Else you can store the crepe stack in the fridge with a foil cover to keep it from dessicating. A day or two should be the maximum : crepes are best fresh.
When you feel like eating a crepe, reheat it on the pan with grated cheese and a slice of ham on top of it, and from time to time an egg for a change – these are the basic classics. I also enjoy a mix of mushrooms and crême fraiche, but you can really fill a crepe with anything that suits your fancy – just open the fridge and try anything…
Make sure you have some lettuce on the side to compensate for all that heavy stuff. Your favorite cider shall go along nicely as cider and crepes are both native of western France.
Each MAC address is supposed to be globally unique. You can change the MAC address when configuring the interface and you can even write a new MAC address to the adapter’s EEPROM. But such alterations are generally only done for testing purposes and the only other excentric use of MAC adressing I know about is giving a Speedtouch Home ADSL modem the Ping of Life. This is because an important feature of the MAC address is that you were supposed to be able to rely on its uniqueness, and many programs assume they can. Mistaken they are ! A large supplier of ADSL modems once shipped us several batches of ADSL modems with variously duplicated MAC addresses. Worse : we accepted them. And we then had to find ourselves another unique identifier for the modems on our network… Just another invalid assumption…
Good feedback about my Jabber presence indicator in a web page
A while ago I built a Jabber presence indicator on my personal web page by customizing one of the examples provided with class.jabber.php. I have received enthusiastic feedback from a handful of users – that makes me feel warm inside ! Do not neglect the ego of people who provide free services, be they Free software developpers or volunteers for anything : a kind comment or a nice stroke in the right direction go a long way toward feeding their motivation. So next time you enjoy the produce of the gift economy be sure to let people know how much you liked it !
With the kind words came a question which made me aware that a newcomer may not find the required configuration as obvious as I do. One of the least obvious steps is telling the script whose status it is supposed to check. Don’t look for a JID parameter inside the presence indicator script : the presence indicator script itself knows nothing about the user whose status it checks. It is the watcher bot user that has the watched user on his roster. The presence indicator script will return the status of anyone on the watcher bot user’s roster. That makes it quite flexible because it will work for any number of users.
If anything remains unclear to you, please be sure to report it to me.
Handspring does not sell spare parts for Treo
Rough handling and repeated falls took their toll on my Treo 650 : the antenna’s root broke and two screws went AWOL. I thought that naturally the manufacturer would sell spare parts but I was wrong : no amount of begging to Palm‘s dreadful telephone support people could convince them to part with some of their apparently precious stock of spares at any price. Same thing with Orange who distributes the Treo 650. The only solution they propose is to send the device into the black hole of their customer support operation and get it repaired at a ludicruous price. This is of course unacceptable.
Happily I found an alternative source : PerformancePDA sells Treo 650 parts at reasonnable prices ! I do not know where they get them from – maybe they disassemble broken devices to get around Palm‘s horrendous spare parts policy. Anyway order fulfillment by PerformancePDA has been fast with no problem. After tightening the minuscule TORX screws my Treo 650 is back in perfect shape. Having it inoperant for a while made me realize how much I depend on it for efficient daily operation…
Bugfix release of the whole maildir lbdb-fetchaddr feeder scripts
A while ago I published lbdb-fetchalladdresses-firsttime.sh and lbdb-fetchalladdresses-daily.sh, two scripts that scour a maildir hierarchy to records all addresses from the headers in the lbdb m_inmail database in order to feed whole maildirs to LBDB for Mutt’s address completion.
A few days ago, for some unknown reasons this script ceased to work correctly. I traced the problem to an incorrect argument to ‘uniq‘. While I was at it I decided to let ‘sort‘ handle the job of ‘uniq‘ and in one fell swoop enhanced the sort operation with some better criterias (-u -d -f -i -k 1,1). So here is version 0.3 for you :
As I mentioned earlier, if you do not have an existing lbdb database, you should run lbdb-fetchalladdresses-firsttime.sh first. Once you have done that you can from time to time update your database with lbdb-fetchalladdresses-daily.sh who does the same thing as lbdb-fetchalladdresses-firsttime.sh but only for messages not older than a certain user-set age.
Attack of the undead /USR/SBIN/CRON
I just maybe apparently (inch’Allah !) about (I am definitely unsure…) got rid of (“solved” would probably be too strong a word for that haphazard process) a very vexing problem that kept me wondering for weeks.
On an otherwise very healthy Debian Linux host I saw idle /USR/SBIN/CRON processes begin to accumulate by the hundreds at a rate of a few every few minutes and after some time inducing significant load although some of them eventually died. Killing them was only a temporary remedy as they kept reappearing. I could not link their appearance to specific cron jobs nor could I link them to a specific command. And hours of sifting through forums and mailing lists yielded nothing conclusive : /USR/SBIN/CRON processes not terminating were not unheard of but their causes seemed to be varied and most often quite mysterious.
Liberal use of strace with various combinations of ‘-p’ ‘-f’ ‘-F’ and ‘-ff’ binding to the running cron daemon process and following vforks showed that the undead processes were left listening on an open connection. I also observed that the /USR/SBIN/CRON spawning was inhibited by an attached strace – in presence of strace the children did receive their missing SIGSTOP. And sometimes days went by with no manifestation of the dreaded processes – but as soon as I thought the problem was solved they began to reappear…
Anyway, finding that the undead processes were left listening on an open connection was the smelly trail I was looking for. ‘netstat -p | grep tcp | grep CRON’ soon showed me that each one of them had an open connexion to the local LDAP server. Then ‘lsof | grep cron | grep ldap’ hinted that it was not the cron process itself that was directly connecting to the LDAP server but an underlying library involved in our PAM LDAP user management system.
Armed with those new results I went hunting for some wild data and found a discussion between Robert Rakowicz and Jerome Reinert about a somewhat similar problem. But the maintenance operations Jerome Reinert suggested on slapd‘s Berkeley DB database did not solve the problem.
For now I have read another post mentioning that versions mismatches and assorted maintainance issues in slapd‘s Berkeley DB database can cause a similar problem. I can’t find the adress anymore but if I do I’ll post it here. We found that a simple slapd restart got us rid of the undead /USR/SBIN/CRON. It has been a few days and I have not seen one again… We keep our fingers crossed – maybe an upgrade silently fixed the problem…
Meanwhile I posted this to debian-user just in case someone there recognizes this problem as something familiar…
Since then I have seen the problem appear again and restarting slapd temporarily fixed it. I am using slapd 2.2.26 from Debian. Maybe I should upgrade to 2.3.23 : although it is available through Debian Unstable it has been released upstream one year ago so maybe I should trust it…
Keep robots off Gallery’s CPU intensive pages
Googlebot indexing Gallery‘s slideshow.html single-handedly brought our server to a crawl. Visits to slideshow.html each produce one Apache process and one Mysql process both pegged at maximum CPU usage. And since the Googlebot visits are quite frequent the processes kept piling up as more were added before the others finished processing the queries. Loads of 30 were not uncommon – something had to be done…
On top of being very CPU intensive, slideshow.html is also totally useless since the information it provides is redundant. So the administrator has every reason to keep the robots from visiting such pages. It took me a discussion with h0bbel to build a working solution that I then recorded in Gallery’s wiki. Thank you h0bbel ! Here is how it goes :
Using URL rewrite module, the default slideshow URL is the following form: “/v/my_album/my_sub_album/my_photo.jpg/slideshow.html“. The problem is that there is no way to exclude that sort of URL in robots.txt syntax. In order to make the URL excludable, some URL rewriting is required.
Happily, there is no need for fiddling with mod_rewrite directly as the nifty rewrite module can handle the details itself. By default the “View Slideshow” rewrite target is “v/%path%/slideshow.html“. The constant slideshow URL mark (“/slideshow.html“) is on the right side of the variable path (“%path%“) and this is why we could not express the slideshow ban in robots.txt syntax. Reversing this order will provide us with an excludable URL.
So we change the rewrite target for “View Slideshow” from “v/%path%/slideshow.html” to “v/slideshow/%path%“. and then add “Disallow: /v/slideshow/” to the site’s robots.txt. If you use the PATH_INFO mode of URL rewrite module then this will be “Disallow: /main.php/v/slideshow/“.
And that’s it: no more spiders hogging our precious resources in vain !
Now in the absence of a centralized multisite administration tool I still have the chore of deploying that solution on each gallery on my host… By the way I wrote a feature request for a one-stop multisite upgrade – use your Gallery forums account to vote for it !
Psi is now my favorite desktop Jabber client
Gaim being evicted from my workstation I went shopping. Gabber and Gabber 2 are no longer developped so that rules them out. Tkabber seems to serve the Jabber hackers well and I found it featureful and highly configurable – I keep it on my shortlist but it does not have the look and feel I am looking for. Gajim looks sweet and solidly gnomish but still a bit wet behind the ears and too simple for my taste. Finally, from my highly subjective point of view it is Psi that strikes the right balance with its good compromise between configurability and simplicity, its excellent coverage of Jabber functionnality and a look and feel to suit my taste. And as a bonus, Psi is available on both Windows and Linux with excellent consistency and Psi will soon feature Jingle. I’m sold !
Gaim cannot set Jabber priority
Gaim does not let the user set the priority of the Jabber client on his workstation. Since I use three different workstations (home, work and mobile), setting Jabber priority is essential so that I get my messages at whichever station I happen to sit or on my mobile when I am not sitting at a desk. So I need another Linux Jabber client…
Ludicruous disk swap space occupation with Exodus.
On my Windows XP workstation at work I found that when receving a message in not yet clearly defined conditions which probably include the message not being aknowledged by the user, Exodus provokes the occupation of about 1 GB of swap space and makes the whole system slow down to a crawl. I went opening a bug report but someone already reported a bug that looked identical to me. So anyway I need another Windows Jabber client…
Bugfix release of the whole maildir lbdb-fetchaddr feeder scripts
A month ago I published lbdb-fetchalladdresses-firsttime.sh and lbdb-fetchalladdresses-daily.sh, two scripts that scour a maildir hierarchy to records all addresses from the headers in the lbdb m_inmail database in order to feed whole maildirs to LBDB for Mutt’s address completion.
A month of running these scripts has revealed a few problems wich are now corrected with a speed optimization thrown in for good measure :
As I mentioned earlier, if you do not have an existing lbdb database, you should run lbdb-fetchalladdresses-firsttime.sh first. Once you have done that you can from time to time update your database with lbdb-fetchalladdresses-daily.sh who does the same thing as lbdb-fetchalladdresses-firsttime.sh but only for messages not older than a certain user-set age.
Class.jabber.php Google Talk compatibility
Nathan Fritz reports Lars Mikkelsen patching class.jabber.php to support Google Talk. Nathan is reviewing the patch and considers including it in a next release of class.jabber.php.
So we learn simultaneously that class.jabber.php does not support Google Talk and that it soon will…
State of JEP-0136 implementation
When I open a chat with a contact from any client, I want to see our past conversation. Jabber server-side message archiving capable is what I need to really make instant messaging the tool it should be. Being a long time user of Dircproxy, an IRC proxy that does just that, I sorely miss it when using Jabber. Now that Google Talk features “Chat History” the clamor from the masses is growing for implementations of Message Archiving as described in JEP-0136.
Right now the only choice seems to be Datasink, an external component that implements Message Archiving (JEP-0136). It is theoritically pluggable into any Jabber server. There is a good recipe for installing Datasink along Ejabberd. But client support is lacking : apart from JWChat I have not found a single client supporting the functionnality provided by Datasink. As the author of Datasink says : “Datasink uses MySQL as storage backend. It’s been written mainly for having a chat history with JWChat as it can’t save to a local disk itself due to security restrictions“. So we can consider that anything else is a lucky by-product.
The Google Talk “Chat History” is not JEP-0136. But as a recent conversation on [jdev] about Google Talk and server-side logging testifies, the topic raises significant interest.
A discussion on the Ejabberd development forum mentions that “JEP-136 seems to be implemented [..] by Jabberd 1.4.5“. But I have found no trace of that anywhere else. Right now, JEP-0136 implementation is a wishlist item for Ejabberd. I’ll think about it for my next letter to Santa Claus.
Sophisticated Web Jabber presence indicator
You may have noticed that I have added a 
to the Jabber presence indicator on my personal web page. It is provided by Edgar, a sophisticated Web Jabber presence indicator based on class.jabber.php. To use the Edgar service, all you need is an image tag such as :
http://edgar.netflint.net/status.php?jid=jim@jabber.grabeuh.com&type=image
Edgar displays status fast because it splits processing in two independant parts sharing a database :
Edgar is licensed under the GPL so you can download it and set it up on your own host.
I like Edgar and I will certainly study it as an exemple of a non-trivial implementation of class.jabber.php. But I shall continue to use my pathetic Web Jabber presence indicator based on one of the examples provided with class.jabber.php because Edgar does not yet display ressources whereas the script I use does.
Tweets by @liotier
