Search Results: "spa"

15 February 2009

Steve Kemp: Imake art, until someone dies

This weekend I have mostly been investigating Common Lisp. If you're new to the environment then you may get started via a simple:
apt-get install clisp
Once you've done that the following resources will help you decide whether you're wasting your time or not: It has been a long time since I've had so much fun - even though the first thing I did was experiment with implementing a spam filter - although in my defense I was only classifying based upon the links contained in the mails. So for example: (NSFW links) ObFilm: Batman

Paul van Tilburg: Lenny Released

The long-awaited, big and stable Debian GNU/Linux Lenny 5.0 has been released! Great job everyone and congratulations! In this release the Debian/Ruby Extra team has an ever greater presence. We were able to increase the number of mainted libraries and applications to over 95 packages. Also quite a lot of issues were resolved and I am proud that we obtained this quality level. For Squeeze we plan to deal with the transition to Ruby 1.9 and with possible multiple interpreter-support (still Ruby 1.8, JRuby?). We might also deal with the gems, who knows? :) P.S. Indeed, did I just started posting without explaining why I was away for over 7 months?

Mark Brown: Upgrading crm114

When upgrading from older crm114 releases and trying to retain your existing configuration it is important to check that all the configuration options that the new version expects to be set have been set. While some will cause errors if they re omitted others will appear to work but will cause unwanted behaviour at runtime. For example, omitting good_threshold and spam_threshold will cause everything to be flagged as spam in X-CRM114-Status even though the classifier is working well. In practice there are relatively few configuration options that users are expected to configure so it may be easier to redo the configuration based on the example provided. For safety it s best to delete your existing CSS files too in case they ve been invalidated by a configuration or format change. It s all a bit manual but it s worth it for what it does for my inbox.

Raphael Geissert: And lenny is out!



Yay!!


$ TZ=US/Samoa date +%d/%m/%y
14/02/09

14 February 2009

Brice Goglin: Debian/X.org notes - Howto get DRI2 on Debian?

Now that the final Mesa 7.3 is available in experimental (and built on most architectures), it is actually easy to get DRI2 in Debian if you have an Intel board. First, make sure you have a recent kernel, otherwise it may fail miserably. I am running 2.6.29-rc here, and I am not even sure 2.6.28 would be enough. Hopefully, one day the driver/server will properly detect and report problems when it runs on a old kernel :) Enable the new UXA acceleration architecture with Option "AccelMethod" "UXA" in the device section of your xorg.conf. Restart X. You should see DRI2 enabled in the log. Now start Compiz and it works. You can see a wobbly glxgears! Well, on my i945, Compiz was very slow by default. I add to disable Sync to-VBlank in the display settings in Compiz' general options. If you don't want Compiz, you may also try running xcompmgr -a and then play with transset to put transparency on 3D applications. Update: Added kernel requirements, added how to make Compiz not slow.
(Permanent link)

Brice Goglin: Debian/X.org notes - X behavior changes in experimental

Apart from interesting features such as DRI2, KMS or input-hotplug, there are some minor changes in X in experimental that actually appear to disturb many users. The first one is that Ctrl-Alt-Backspace does not kill X anymore. There is no easy consensus here, but many people were annoyed of killing X by mistake, so it's disabled by default now. To reenable it, add to the ServerFlags section of your xorg.conf:
        Option "DontZap" "off"
Another one is the background during X startup. Say goodbye to the old well-known grey background. Now you get a black background by default. To revert to the old behavior, pass -retro on the server command line (for instance in /etc/X11/xinit/xserverrc). Note that this option also reenables Ctrl-Alt-Backspace killing the server. Finally, you might also see glxgears reporting very low frame rates (60) on some hardware. Well, please remember that it is not a benchmark, the output basically means nothing. This is why some distros even removed the fps output by default. The thing is that recent DRM stacks will just synchronize frame rendering on vertical blanks (can anybody here see 1000fps with human eye?). So if you have a 60Hz refresh rate, glxgears will report 60fps, that's it. But it has nothing to do with DRI or 3D being slow. Please try some relevant 3D programs or benchmarks before complaining :)
(Permanent link)

Russell Coker: Do Spammers target Secondary MX Servers

Rumour has it that some types of spammer target the secondary MX servers. The concept is that some people have less control over the secondary MX server and less ability to implement anti-spam measures. Therefore if they accept all mail from the secoondary then a spammer will have more success if they attack the secondary server. True secondary servers are becoming increasingly uncommon, the lower priority servers listed in MX records tend to have the same configuration as the primary, so the benefit for the spammer in attacking the secondary server is probably minimal. But it would be good to know whether they do this. I decided to analyse the logs from a mail server that I run to see if I can find evidence of this. I chose a server that I run for a lient which has thousands of accounts and tens of thousands of messages delivered per day, my own server doesn t get enugh traffic to give good results. I analysed the logs for a week for the primary and secondary MX servers to see if the ratio of spam to ham differed. Now this does have some inherent inaccuracy, some spam will slip past the filters and occasionally a legitimate email will be rejected. But I believe that the accuracy required in a spam filter to avoid making the users scream is vastly greater than that which is required to give a noteworthy result. I produced totals of the number of messages delivered, the number rejected by SpamAssassin (which has a number of proprietary additions), the number of message delivery attempts that were prevented due to rate limiting (most of which will be due to spammers), and the number of attempts to deliver to unknown accounts (some of which will be due to spammers having bad addresses in their lists). For each of these rejection criteria I produced a ratio of the number of rejections to the number of delivered messages for each of the servers. The rate limit count didn t seem useful. While the primary server had a ratio of 0.75 messages rejected due to rate limiting to every message accepted the secondary had a ratio of 0.08. It seems that the secondary just didn t get enough traffic to trigger the limits very often. This is an indication that the more aggressive bots might not be targetting the secondary. The ratio of messages rejected by SpamAssassin to legitimate mail was 0.76:1 on the primary server and on the secondary server it was 1.24:1. The ratio of messages addressed to unknown users to successful deliveries was 3.05:1 on the primary and 7.00:1 on the secondary! This seems like strong evidence to show that some spammers are deliberately targetting the secondary server. In this case both the primary and secondary servers are in server rooms hosted by the same major ISP in the same region. The traceroute between the two mail servers is only 7 hops, and there is only one hop between the two server rooms. So it seems unlikely that there would be some connectivity issue that prevents spammers from connecting to the primary. One other factor that may be relevant is that the secondary server has been in service for some years while the primary is only a few months old. Spammers who store the server IP address with the email address (which happens - change the DNS records to send your mail to a different server and you will see some spam go to the old server) will be sending mail to what is now the secondary server. The difference in the rejected mail volume on the secondary server and the amount that would be rejected if it had the same ratio as the primary amounts to 7% of all mail rejected by SpamAssassin and 14% of all mail addressed to unknown users. I think it s unlikely that any significant fraction of that would be due to spammers caching the server IP address for months after the DNS records were changed. So therefore it seems most likely that something between 7% and 14% of spam is specifically targetted at the secondary server. While the ratio of spam to ham seems significantly worse on the secondary it is still a relatively small portion of the overall spam sent to the service. I had been considering setting up secondary mail servers with extra-strict anti-spam measures but the small portion of the overall spam that is targetted in such a way indicates to me that it is not going to be worth the effort. Another thing that has occurred to me (which I have not yet had time to investigate) is the possibility that some spammers will send the same messages to all MX servers. If that happens then the ratio of spam to ham would increase every time the number of MX servers is increased. In that case it would make sense to minimise the number of MX servers to reduce the amount of CPU power devoted to runing SpamAssassin. Note that I have intentionally not given any numbers for the amount of mail received by the service as it is a commercial secret. Update: One thing I realised after publishing this post is that the secondary MX server is also the main server for mail sent between local users. While the number of users who send mail to other users on the service is probably a small portion of the overall traffic (it s not a really big ISP) it will make a difference to the ratios. Therefore the ratio of spam to ham would be even worse on the secondary MX (assuming for the sake of discussion that local users aren t spamming each other).

12 February 2009

Ana Beatriz Guerrero Lopez: FOSDEM 2009

Some stuff I want to reminder for next year s FOSDEM:

Ingo Juergensmann: Automatically restore files from lost+found

I already wrote two days ago about it, but the problem then was to find a way of unique identifiers for files. Using md5sum and openssl sha1 seemed to deliver multiple files for each hash, which confused me.
A closer look later revealed that there were in fact multiple times the same file, so the same hash is of course correct.

Anywa, I'm now using the following two scripts to create an index file about the content of my filesystems and to be able to restore files from lost+found.

CODE:
#!/bin/bash
#
# Usage: ./make-lsLR.sh
#
# Purpose:
# to make a file that is parseable for recovering
# a filled /lost+found directory by parsing
# filesize, md5sum, permisions and path+filename
#
# Author: Ingo Juergensman - http://blog.windfluechter.net
# License: GPL v2, see http://gnu.org for details.
#
# first: get all directories
nice -15 find / -path /sys -prune -o \
-path /proc -prune -o \
-path /var/lib/backuppc -prune -o \
-path /var/spool/squid -prune -o \
-type d -print > /root/ls-md5sum-dirs.txt


# next: get all relevant information
nice -15 find / -path /sys -prune -o \
-path /proc -prune -o \
-path /var/lib/backuppc -prune -o \
-path /var/spool/squid -prune -o \
-type f -printf "%s %U:%G %#m " \
-exec nice -15 md5sum \; tr -s " " > /root/ls-md5sum-files.txt


CODE:
#!/bin/bash
#
# usage: check_lostfound.sh <pathtolost+found> [make_it_happen]
#
# Purpose: to find files in lost+found and trying to restore
# original files by comparing ls-md5sum-files.txt (generated by
# make-lsLR.sh
# Option make_it_happen cause the data actually being written/moved
# whereas the script runs in dry mode per default.
#
# Author: Ingo Juergensman - http://blog.windfluechter.net
# License: GPL v2, see http://gnu.org for details.
#
PFAD=$1
dry=$2

# generating md5sum/information of lost+found
echo "Examing $ PFAD /lost+found..."
find $PFAD/lost+found -type f -printf "%s %U:%G %#m " -exec nice -15 md5sum \; > /root/lostfound-files.txt


# creating missing directories if necessary by parsing ls-md5sum-dirs.txt
echo "Creating missing directories..."
for dir in cat /root/ls-md5sum-dirs.txt sed -e 's/\ /,/g' ; do
dir= echo $ dir sed -e 's/,/\ /g'
if [ ! -d "/space/check_lostfound/$ dir " ] ; then
echo " Missing dir "$dir" - creating..."
if [ "$dry" = "make_it_happen" ]; then
mkdir -p "/space/check_lostfound/$ dir "
fi
fi
done


# next, get the md5sum of files in lost+found and compare it
# against stored md5sum in ls-md5sum-files.txt
echo "Restoring/moving files..."
for z in cat /root/lostfound-files.txt tr -s " " sed -e 's/\ /,/g' ; do
z= echo $z sed -e 's/,/\ /g'

size1= echo $z awk ' print $1 '
ugid1= echo $z awk ' print $2 '
perm1= echo $z awk ' print $3 '
md5s1= echo $z awk ' print $4 '
path1= echo $z awk ' print $5 '

file= grep -m 1 $md5s1 /root/ls-md5sum-files.txt
if [ ! -z "$ file " ] ; then
file= echo $file sed -e 's/,/\ /g'
size2= echo $file awk ' print $1 '
ugid2= echo $z awk ' print $2 '
perm2= echo $file awk ' print $3 '
#md5s2= echo $file awk ' print $4 '
path2= echo $file awk ' print $5 '

if [ ! -e /space/check_lostfound/$ path2 ]; then
echo "$path1 -=> $path2"
if [ "$dry" = "make_it_happen" ]; then
cp "$ path1 " "/space/check_lostfound/$ path2 "
fi
fi
fi
done


It's actually working for me, but use them at your own risk - as always! ;)

Anyway, there are some drawbacks with these versions:

  1. it is dog slow. Grepping through 75M of ls-md5sum-files.txt for each file found in lost+found is CPU-intensive and slow.

  2. files with spaces in their names are not handled well. In fact they are not handled properly at all. You'll get "file not found" errors for each filename with spaces.

  3. currently grep -m 1 stops grepping when the first match was found.



If anyone has an idea how to speed up the script or improve it otherwise, please let me know! I already though by myself to remove found files from ls-md5sum-files.txt to reduce the workload on grepping every time all of the 75M and to work around the last point from above. But rewriting the file everytime a fiel was found and moved will put extra workload on disk I/O, which - of course - will get better over time because the file gets smaller. Another idea was to store the file within an array in memory, but then I would prefer to use a Python script for this purpose.

So, when you have some ideas, tips or improvemts, please comment!

Eddy Petri&#537;or: autohibernate, zenity and cron

I have been trying to make a script that should put my laptop into hibernate, run automatically from cron, so it forces me to get to sleep.

I had managed to make it work from a console (tty1), but it seemed as if it refused to work from cron.

During the tests my local mailbox was getting the output of the command, and I stood and watched at this error message for more than an hour trying to figure out what was wrong. I couldn't understand what was wrong:


This option is not available. Please see --help for all possible usages.

This was from zenity and I was starting to suspect that it was failing to expad properly the text variable since it worked with a fixed text.

This was failing:

(...) /usr/bin/zenity --progress --auto-close --text "'$NOTIFICATION$XMSG'"

And this was working:

(...) /usr/bin/zenity --progress --auto-close --text "OH!MY!GOD!"


I couldn't figure it out. Until I tried this:

(...) /usr/bin/zenity --progress --auto-close --text "OH!MY!GOD! "


And it failed.


God damn! Setting LANG in the script fixed the issue right away!


So, if you ever want zenity to show up from cron dont forget to:
zenity is a pice of shit when it doesn't work. It could have printed the "option which wasn't available".

11 February 2009

David Moreno: Debian get-together in NYC this next 1234567890

So, Biella already posted a reminder, and I m doing it again on my blog, here.
Attention New York City Debianistas,
The astrological confluence of 1234567890[0], the impending release of
Lenny[1], and the odd sighting of a horned mythical beast that
cryptozoologists are calling a 'new FTP-master-assistant/slave' being
sighted in the mist off the shores of the East River[2] will result in
all emacs users to transcend and all vim users to be transponded to
their respective motherships, which are scheduled for near-orbit on that
night.
You will only be taken if you have a sip of beer on the 13th, before
6:31:30pm at the Pacific Standard[3]. 
If you come late, you may suffer nano for all eternity.
Micah
ps. All nano users will be Left Behind  to tend to the servers that we
did not bring with us on the Rapture  rickshaw. 
ps. lets keep the the post-apocalyptic space editor battle that will
erupt between the S.S. Church of Emacs, and the H.R.H VIMperator
mothership for later, and drink with revelry together now.
0.  date -d '@1234567890' 
1. http://lists.debian.org/debian-devel-announce/2009/02/msg00000.html
2. http://lists.debian.org/debian-devel-announce/2009/01/msg00004.html
3. http://www.pacificstandardbrooklyn.com
Don t be late, it s at 1234567890!

Biella Coleman: Finally

Not so long ago, I was lamenting to some Debian developer about how LONG it took for me to write stuff, of any quality at least. And aside from my own slowish pace, the academic publishing process is slow as molasses. The two together make for a deadly combo. This friend reminded me that Debian took a heck of a long time to release and at the time, this reminder actually made me feel a lot better. Well, after years of toiling, updating, bug squashing, and lots of lots of arguing, Lenny is coming out and those of us in NYC are celebrating. Though this has been circulated on the Debina-nyc list, it never hurts to circulate a little wider, especially for this event.
Attention New York City Debianistas, The astrological confluence of 1234567890[0], the impending release of
Lenny[1], and the odd sighting of a horned mythical beast that
cryptozoologists are calling a new FTP-master-assistant/slave being
sighted in the mist off the shores of the East River[2] will result in
all emacs users to transcend and all vim users to be transponded to
their respective motherships, which are scheduled for near-orbit on that
night. You will only be taken if you have a sip of beer on the 13th, before
6:31:30pm at the Pacific Standard[3]. If you come late, you may suffer nano for all eternity. Micah ps. All nano users will be Left Behind to tend to the servers that we
did not bring with us on the Rapture rickshaw. ps. lets keep the the post-apocalyptic space editor battle that will
erupt between the S.S. Church of Emacs, and the H.R.H VIMperator
mothership for later, and drink with revelry together now. 0. date -d @1234567890
1. http://lists.debian.org/debian-devel-announce/2009/02/msg00000.html
2. http://lists.debian.org/debian-devel-announce/2009/01/msg00004.html
3. http://www.pacificstandardbrooklyn.com

Biella Coleman: Finally

Not so long ago, I was lamenting to some Debian developer about how LONG it took for me to write stuff, of any quality at least. And aside from my own slowish pace, the academic publishing process is slow as molasses. The two together make for a deadly combo. This friend reminded me that Debian took a heck of a long time to release and at the time, this reminder actually made me feel a lot better. Well, after years of toiling, updating, bug squashing, and lots of lots of arguing, Lenny is coming out and those of us in NYC are celebrating. Though this has been circulated on the Debina-nyc list, it never hurts to circulate a little wider, especially for this event.
Attention New York City Debianistas, The astrological confluence of 1234567890[0], the impending release of
Lenny[1], and the odd sighting of a horned mythical beast that
cryptozoologists are calling a new FTP-master-assistant/slave being
sighted in the mist off the shores of the East River[2] will result in
all emacs users to transcend and all vim users to be transponded to
their respective motherships, which are scheduled for near-orbit on that
night. You will only be taken if you have a sip of beer on the 13th, before
6:31:30pm at the Pacific Standard[3]. If you come late, you may suffer nano for all eternity. Micah ps. All nano users will be Left Behind to tend to the servers that we
did not bring with us on the Rapture rickshaw. ps. lets keep the the post-apocalyptic space editor battle that will
erupt between the S.S. Church of Emacs, and the H.R.H VIMperator
mothership for later, and drink with revelry together now. 0. date -d @1234567890
1. http://lists.debian.org/debian-devel-announce/2009/02/msg00000.html
2. http://lists.debian.org/debian-devel-announce/2009/01/msg00004.html
3. http://www.pacificstandardbrooklyn.com

Jon Dowland: use of unstable

I've seen a few posts (1,2,3) from people recently who are announcing new software uploaded to unstable. It's my understanding that, even in freeze time, unstable is designed to be for packages which are supposed to be going into the next release. Therefore packages which are intended for the release after that (lenny+1) should not be uploaded to unstable until Lenny is out. Perhaps experimental is more appropriate (that's where I've put a few of my such packages). Please correct me if I'm wrong.

Enrico Zini: DDE, Debian Data Export

DDE, Debian Data Export After testing the idea and the prototype with my presentation at Fosdem, I'm proud to announce DDE, Debian Data Export. The problem In Debian, we publish all sort of information, using all sorts of data formats (often ad hoc and obscure), in obscure places. Try to think of an application, for example, that wants to access all this information together: A nightmare, uh? The solution DDE is a way to make it simple to publish and download data. The aim is to be able to access all sorts of Debian information without worrying about data formats, protocols and access control, and to make it easy to discover what data is available. DDE exports data as a big virtual tree. You can pick a node in the tree by its URL and download all the data that it contains, in a format of your choice: currently it supports JSON/JSONP, YAML, CSV and Python pickled objects. This means that you can now get Debian data using a trivial HTTP client tool or library, and read it using commonly available decoders: both should be available in almost any programming language nowadays. Since JSON and JSONP are supported, this even includes JavaScript in Ajaxy web pages. DDE is not a competitor to UDD: UDD is about creating a central location where all the data can be accessed, while DDE is about giving people a simple way to access data or subsets of data. In a way, DDE and UDD complete each other: the more data enters UDD, the more data is available for DDE. In turn, DDE gives a simple interface to the most popular and useful UDD queries. The dream Here are some hints at what can be done with this: A call for action You can add data to the DDE tree by just putting a data file in yaml, json or pickle format under ~/.dde (I've written a specific guide to this on the Debian wiki). If you wish to create new and fancy Debian statistics or compute other sorts of data, or if you already maintain tools that generate Debian data, including but not limited to, for example: Then please have a look at http://wiki.debian.org/DDE/StaticData and try to publish your data in ~/.dde on merkel.debian.org. For more complicated cases (like accessing a remote database), it is possible to extend DDE via python plugins. You can get in touch with me if you need to go that way.

Julien Danjou: OpenOffice is better as a pager than as a text processor

Since several month, awesome users have reported a bug with OpenOffice.org. When using OOo and clicking on a menu, or using the mouse wheel to read a document, the currently selected tag (desktop) will change automagically to another one. I've digged into awesome and found that awesome received a _NET_CURRENT_DESKTOP request. As defined by EWMH, this kind of request are sent by a pager to change the active desktop. That was weird. Nobody is using a pager here. So, I just kicked my gdb out, attached it to OOo, breaking on XSendEvent call. And I got it:
Breakpoint 1, XSendEvent (dpy=0x1a00080, w=483, propagate=0, event_mask=1572864, event=0x7fff1fd70d70)
   at ../../src/SendEvent.c:46
(gdb) bt
#0  XSendEvent (dpy=0x1a00080, w=483, propagate=0, event_mask=1572864, event=0x7fff1fd70d70)
   at ../../src/SendEvent.c:46
#1  0x00007f8c0ab4193f in vcl_sal::WMAdaptor::switchToWorkArea ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#2  0x00007f8c0aafdbd8 in X11SalFrame::Show ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#3  0x00007f8c1378623c in Window::Show ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#4  0x00007f8c13785f40 in Window::Show ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#5  0x00007f8c1372cb54 in FloatingWindow::StartPopupMode ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#6  0x00007f8c1373c877 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#7  0x00007f8c1373ccf2 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#8  0x00007f8c1373ce84 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#9  0x00007f8c13795e7f in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#10 0x00007f8c13797e74 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#11 0x00007f8c13796748 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#12 0x00007f8c0aafe6f8 in X11SalFrame::HandleMouseEvent ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#13 0x00007f8c0ab040c2 in X11SalFrame::Dispatch ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#14 0x00007f8c0ab31625 in SalX11Display::Yield ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#15 0x00007f8c0ab356f3 in ?? () from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#16 0x00007f8c0ab2df1f in SalXLib::Yield () from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#17 0x00007f8c135b050e in Application::Yield ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#18 0x00007f8c135b0587 in Application::Execute ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#19 0x00007f8c17517e80 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libsofficeapp.so
#20 0x00007f8c135b4b24 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#21 0x00007f8c135b4bc5 in SVMain () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#22 0x00007f8c1754ca6c in soffice_main ()
  from /usr/lib/openoffice/program/../basis-link/program/libsofficeapp.so
#23 0x000000000040105b in main ()
I started digging more into the code, and this is what I finally found in salframe.cxx:
       // #i45160# switch to desktop where a dialog with parent will appear 
       if( mpParent && mpParent->m_nWorkArea != m_nWorkArea ) 
           GetDisplay()->getWMAdaptor()->switchToWorkArea( mpParent->m_nWorkArea );
Beautiful! It even has a comment with a IssueZilla bug number. Let's go and see where it comes from. After 10 minutes of research to find that fucking IZ, I finally found the link to the issue #45160. The bug is IMHO not related to OOo but to a window manager doing poor job. I've found that an awesome user already reported an bug err, wait, I mean an issue as issue #96684 (remember there's no bug in OOo, only issues) and I commented about it. UPDATE: It seems OOo developers have agreed to fix that bug eventually.

Uwe Hermann: Miro 2.0

Miro 2.0 announce image It's been announced at quite a few places, so you probably already heard about it: Miro 2.0, the new major release of the cross-platform Internet RSS audio/video aggregator and player has been released. Miro is available for Linux, Windows, and Mac OS X, the new release on Linux now features a "native" GTK+ widgets UI (instead of the Mozilla-based HTML widgets of earlier versions) and supports both a xine, as well as gstreamer renderer (for audio and video). Miro 2.0 feed list I won't even attempt to list all the improvements and new features, please check the release notes and the feature list for details. Overall more than 670 issues have been fixed since the last 1.2.x series release. You can also watch this video (Ogg Theora, 10 MB) for a short introduction in Miro 2.0. Together with the software release, the getmiro.com website, as well as the online Miro Guide have been competely rewritten and are a lot more usable and better-looking than before. Finally, I have uploaded a new Miro 2.0 Debian package to unstable yesterday, by now it should be available from most mirrors. For Debian we're defaulting to xine at the moment, but please consult README.Debian if you want to switch to the gstreamer backend. Please test the new release extensively so the few remaining issues (if any) can be ironed out soon...

Jaldhar Vyas: DNS The MNS

On Monday, I was informed that my server (a xen instance hosted at Brainfood was chewing up a lot of bandwidth by giving out long DNS responses at the rate of several per second. According to Peter Palfrader, it was most likely due to this DoS attack. Apparently I was contributing to the problem because my name server (running bind9 ) was accepting queries from anywhere on the Internet. You can test this via an online tool from SANS or by issuing the following command from a machine which is not on your network.
dig -t ns @your.name.server
If the status that comes back is NOERROR, you have a problem. The fix is to restrict the IPs you allow queries from by adding the allow-query directive to your bind configuration. If you are using the stock Debian setup, add it in the options stanza in /etc/bind/named.conf.options Because all my services run on one machine, I did it like this:
allow-query   localhost;  ;
If yours are spread out over several hosts, you need to add all their IPs. If you are authoritative for any zones, you want to allow queries from anywhere so add
allow-query   any;  ;
to the stanza for each zone. In a stock Debian setup, these are in /etc/bind/named.conf.local Once you have done this and restarted bind, go back to the online tool or run dig again. If status is REFUSED, congratulations you have saved the Internet.

10 February 2009

Vincent Fourmond: A makefile snippet for generaring ray-traced images from pymol

For my research, to create neat images of the molecules I study, I use Pymol. It's free, part of Debian, command-driven, very powerful and it produces really good-looking pictures. Although, admittedly, if you don't buy a subscription, the documentation is rather sparse. I'm using scripts to generate ray-traced pictures, but I can't include the ray command directly in the scripts, as Pymol would not give me the opportunity to change anything before tracing (and things I trace take loads of time...). So I write a ray command, but I comment it out, such as in the following example, cytochrome.pml:
load http://www.rcsb.org/pdb/files/1c6s.pdb
hide everything
show sticks, (resname HEC)
color orange, (resname HEC)
show cartoon
bg_color white
set_view (\
     0.939850032,    0.167392358,    0.297758341,\
     0.336208642,   -0.299271941,   -0.892972171,\
    -0.060366094,    0.939367712,   -0.337551534,\
     0.000000000,    0.000000000, -106.161231995,\
    33.668910980,   -4.749122620,  -24.822664261,\
    -9.742469788,  222.064941406,    0.000000000 )
# ray 800,800
So, to easily generate PNG images from such a file, I wrote the following makefile snippet, that does the job (as demonstrated by the figure on the right, produced by this very snippet ran on the cytochrome.pml file above):
%.png: %.pml
 cd $(dir $<); \
 ray_trace_args= grep -o 'ray.*' $(notdir $<)  tail -n1   egrep -o '([0-9, ]+)'   sed 's/ //g'  ; \
 pymol -c -d "@$(notdir $<)" -d "cmd.ray($$ray_trace_args)" -g $@
I hope this snippet will prove useful for others. At any rate, it will prove useful for me ! Just for the record, this protein, represented in cartoon view, is called cytochrome c6 and is one of the proteins implied in the photosynthesis of some organisms.

Gunnar Wolf: dh-make-drupal - Easily debianize Drupal modules, themes

I have spent a couple of days working into dh-make-drupal. Yes, you guessed right: An idea based on the wonderful dh-make-perl, but applied to the Drupal Content Management System.
Drupal's greatest strengths, IMHO, are: Yup, even though I am quite fond of its flexibility and power, I fell for Drupal in no small part because of its sysadmin-friendliness. Now, I hate having non-Debian-packaged files spilled over my /usr/share partition. Drupal modules want to be installed in /usr/share/drupal5/modules/module_name (or s/5/6/ for Drupal6, to which I have not yet migrated). For that reason, over the last year I have been growing my personal apt repository of Drupal stuff. Yes, it is still on, and I don't plan on taking it off. You can access it by adding deb http://www.iiec.unam.mx/apt/ etch drupal to your /etc/apt/sources. However, you can now also do the process locally. Do you fancy the wonderful Biblio module? Or the very nice Abarre theme? Great!
  1. 0 gwolf@mosca 4 /tmp$ ~/code/dh-make-drupal/dh-make-drupal --drupal 5 biblio
  2. 0 gwolf@mosca 5 /tmp$ cd drupal5-mod-biblio-1.16/
  3. 0 gwolf@mosca 6 /tmp/drupal5-mod-biblio-1.16$ debuild -us -uc >& /dev/null
  4. 0 gwolf@mosca 7 /tmp/drupal5-mod-biblio-1.16$ cd ..
  5. 0 gwolf@mosca 8 /tmp$ su
  6. Password:
  7. 0 root@mosca[1]/tmp# dpkg -i drupal5-mod-biblio_1.16-1_all.deb
  8. Selecting previously deselected package drupal5-mod-biblio.
  9. (Reading > database ... 275110 files and directories currently installed.)
  10. Unpacking drupal5-mod-biblio (from drupal5-mod-biblio_1.16-1_all.deb) ...
  11. Setting up drupal5-mod-biblio (1.16-1) ...
Yay! Yes, still many more things to come (i.e. including the debuild call and whatnot), but... Enjoy! BTW, this piece of software owes a couple of beers to Why the lucky stiff, author of Hpricot. You are insane (but we are all well aware of that). You deserve to go to the webscraping heaven. Yes, besides the programming-languages-teaching-cartoon heaven. You find out how to split the time between them. [Update]: Of course, ITP bug #514786 has been filed, and I will soon be uploading this into Debian.

Next.

Previous.