Sorry for the hideously late announcement, but an extraordinary comedy of
errors involving quite a long chain of people and a series of unfortunately
timed holidays meant we couldn't confirm this until now.
this weekend while giving a bit of TLC to the php packages, i
thought i'd finally get around to tackling #490023 and similar bugs, which
meant learning about how to use the triggers feature provided by
dpkg.
unfortunately documentation for this feature was in fairly short
supply, and after extensive searching (and by extensive searching i
mean typing "dpkg triggers howto" into a google search) i had a
couple short manpages (dpkg-trigger(1) and deb-triggers(5)) and an
overly verbose and possibly out of date
/usr/share/doc/dpkg/triggers.txt.gz. none of these documents really
gave a clear "big-picture" for how to get going either.
so, as is often the case, i got distracted from my intended task
and ended up on a little side-project putting together a nice
howto/tutorial for how to integrate dpkg triggers into a package.
note that there may be misunderstandings or inaccuracies in the
document, as it's based on an afternoon's worth of hacking and
q&a directed at #debian-dpkg (thanks to Guillem and Rapha l for fielding those
questions). so if i'm off on anything, please feel free to let me
know!
to get started:
git clone http://git.debian.org/git/users/seanius/dpkg-triggers-example.git
postinst triggered "<trigger1> ... <triggerN>"
interest /path/to/a/directory
interest my-second-trigger
One of my professional duties in my past ten years was monitoring systems. Even my diploma thesis was dedicated to distributed monitoring (altough my professor sucked badly). Apart from a few custom-programmed scripts to analyze special situations (e.g. proxy clusters) I used tools that fellow administrators will find familiar: Nagios and Cacti. And another less famous text-configuration-based monitoring tool called Cricket. That worked well somehow but Cricket was hard to learn for my coworkers and Cacti seems unreliable and fundamentally broken in terms of SNMP checking. Besides why do I have to set up availability checking in Nagios and set up checking of the same parameters in another software to draw graphs?
Just recently I came across an open-source software I hadn t heard of before: Zabbix. And although it has a few rough edges it seems way more professional than other common tools (the commercial tools I saw are even worse than the open-source variants). I tried it and after a lot of reading and trying it looks like it has a good potential to replace Nagios and Cacti. So I thought I d sum up my personal experiences with all of these tools.
Nagios. Their makers claim that it s the industry-standard in IT infrastructure monitoring . Honestly it s a great tool but considering how many years it has been existing it barely evolved. During my diploma thesis I wrote an alternative software that I called MrNetwork that dealt with flaws that Nagios hasn t even fixed today. Still Nagios is a tool I have used for many years and it is very reliable.
Advantages:
Advantages:
Advantages:
Advantages:
\userouthertheme singletree
Posted in english 
I was really happy a few years back, when Martin announced he'd start working
on netconf. Not just
because I agreed with his assessment that ifupdown needed replacement;
also because I had been thinking about a good way to implement such a
thing, and had been planning to start writing 'soon'. With Martin's
announcement, I made a few suggestions to give him some input, and then
put my plans away I had more important things to take care of,
anyway.
Unfortunately, netconf did not manage to reach the ambitious goals
that Martin set out, mainly due to lack of contributors. I wanted to
help out; I really did. But Martin's choice of python to implement a
'prototype' which then had to be reimplemented in C or C++ didn't get me
very thrilled. Not just because I have a severe dislike of python; also
because implementing something twice is, in my humble opinion, not quite
the best way to do something like this.
But hey, who am I, if I don't put my code out there.
Never the less, I tried helping. I really did. During debconf8 at Mar
del Plata, I approached Martin with the suggestion that I start
reimplementing those bits that were unlikely to change anymore in C, as
a first step toward something that could be in the base system.
Unfortunately, that didn't happen. After trying for about two weeks, I
just gave up. I thought I could read python code and
reimplement that so that it would work the same way, but I couldn't. I
thought I could implement python modules in C without knowing
python, but as it turns out that's a laughable idea.
For several months then, I didn't think about it anymore. In March of
this year, however, I got a little bored. And what does one do when they
get bored? Right, you find something to do. I my case, that was 'figure
out how bison works'. I'd of course known about parser generators for
quite a while, but just never had the time to dive in deep and figure
out how they work. When I needed to do a config file for nbd, I instead hand-wrote my
parser and used a lexer from libglib. But I wanted to learn how to do
things properly, so I sat down.
Long story short, when I had to choose something somewhat more
complex to implement, I thought 'how about a hypothetical config file
for a network configuration utility', and I started implementing that.
It turned out to be fun, so I didn't stop after I knew enough about
bison. And just last week, for the first time I successfully used it to
bring up my wired interface using DHCP -- and bring it down again. It
can also already manage static interfaces through netlink, though it
isn't quite able to the equivalent of 'ip addr flush' yet.
Fun.
The system is quite flexible. It has a plugin interface (which
needed some refinement that I did using some help on IRC just today),
which should allow developers to implement extra functionality by just
dropping a shared object in the right directory. In fact, I'm working on
the wireless support (hence my blog post of last
week) as a plugin.
Obviously the code isn't remotely ready yet. The wireless code has a
long way to go. The firewall module needs to be started. It will
probably crash and burn if put to the test. But even so, it already has
one feature that ifupdown, in its 10 years of existence, never acquired:
it will not try to DHCP off an interface if it finds out that
there is no cable connected to it unless you wrote a configuration
that asks you to do so.
I wanted things to be as simple as possible, and therefore the
minimal valid configuration file that will do something useful is the
following:
That's right, it's empty. This will cause the system to bring up the
'lo' interface at bootup, and do nothing else. If you say 'ifup eth0',
where eth0 is a valid and existing interface, it will first check
whether there is a link, and if so, DHCP off of it.
There's much to do still, but I have now reached a point where I feel
the system is ready to meet all challenges it should be able to meet (or
so I hope), and where it might be nice if interested people check it
out.
The code is in a git repository that's mirrored on git.debian.org,
github.com, and my own git.grep.be. The latter
is my --mirror repository, but is not available for cloning to anyone
else. If you're interested in checking it out, you may want to start
with doc/tech.txt, and/or examples/ipcfg.cfg. I updated the former just
yesterday, so it's quite up-to-date. On the other hand, while the latter
shows the direction I would like the system to take, the code is a far
cry from implementing everything shown there, and it has been a while
since I last checked that file out, so the comments in there are, in
some cases, somewhat outdated. But that's good, because I want to keep
the file as a reference of the goals that I originally had, before I'd
written this whole corpus of code, so that I can go back at some
undefined point in the future and fix things.
Comments are (more than) welcome.
Modern daemon implementations can be run in a variety of ways, in a range of contexts. The daemon software itself can be a useful tool in environments where the associated traditional system service is neither needed nor desired. Unfortunately, common debian packaging practice has a tendency to conflate the two ideas, leading to some potentially nasty problems where only the tool itself is needed, but the system service is set up anyway. How would i fix it? i'd suggest that we make a distinction between packages that provide tools and packages that provide system services. A package that provides the system service foo would need to depend on a package that provides the tool foo. But the tool foo should be available through the package manager without setting up a system service automatically. Bad Examples Here are some examples of this class of problem i've seen recently: Packages that include daemons for system services should place scripts in /etc/init.d to start or stop services at boot time or during a change of runlevel.I feel like this particular conflict must have been hashed out before at some level are there links to definitive discussion that i'm missing? Is there any reason we shouldn't push in general for this kind of distinction in debian daemon packages? Tags: daemons, packaging, policy
Here are some notes about bootstrapping a Centos or Fedora chroot from Debian. It should also work from Ubuntu with minor changes, but I haven t checked. The following should really be done in a chroot, since some commands will install files in your /etc or elsewhere, ignoring the --installroot passed to yum. The following instructions are for Centos, but replacing all occurences of centos with fedora should work.
apt-get install yum rpm python-m2cryptoapt-get install -t experimental rpm (needed because some packages, like bash, require features not available in unstable s rpm package error message about rpmlib(BuiltinLuaScripts)).mkdir -p /tmp/centos/var/lib/rpmrpm --root /tmp/centos --initdbrpm -ivh --force-debian --nodeps --root /tmp/centos centos-release*rpm (that populates /tmp/centos/etc with information about the centos repositories)yum --installroot /tmp/centos/ install yum . That fails because of missing GPG information in /etc/pki. Do ln -s /tmp/centos/etc/pki /etc/pki, then again yum --installroot /tmp/centos/ install yum.mount -t proc foo /tmp/centos/procmount -t sysfs foo /tmp/centos/syschroot /tmp/centos /bin/bash --logincd /var/lib/rpm && rm * (simplest way to avoid problems between db versions for Debian s RPM and centos RPM)rpm --initdbyum install yum (again, to restore the rpm db)yum install vim-minimal less Subscribing to packages on the PTS is really useful to stay informed of everything happening with those packages. Unfortunately, managing your PTS subscriptions is really a challenge. Here is how I proceed to subscribe to packages I forgot to subscribe after uploading them:
/org/packages.qa.debian.org/bin/get-summary-subscribers.pl grep your@emailpsql -A -t service=udd -c "select source from sources
where distribution='debian' and release='sid'
and maintainer_email='your@email'
union select source from uploaders
where distribution='debian' and release='sid'
and email='your@email';"
- You can them use
combine to find the packages you should subscribe to, and mass-subscribe using the email interface.
- Then, you are done, or almost done: mass-confirming PTS subscriptions is a PITA because of #340863.
Some more info:
- The PTS lives on master, in
/org/packages.qa.debian.org.
- The script that handles emails send to pts@ is
bin/control.pl.
- The spool dir for pending requests is
spool/. The files are simple text files.
- You can send multiple commands per email. Sending them in the subject might be broken. (at least it failed for me)
- You don't need to take special care of the From for your emails. It's ignored (unless you subscribe without specifying an email address).
Andrew, I bought those wootoff lights as well, and have them connected to a hub on my mythtv system so I can activate them with a remote. I use the hub-ctrl.c utility from this page with this simple wrapper script that searches for the hub:
#!/bin/sh bus=$(lsusb grep TUSB2046 cut -d' ' -f2) dev=$(lsusb grep TUSB2046 cut -d' ' -f4 sed 's/:$//') port=4 hubctrl=/home/dannf/hub-ctrl if $hubctrl -b "$bus" -d "$dev" -v grep "Port $ port :" grep -q power; then toggle=0 else toggle=1 fi $hub-ctrl -b "$bus" -d "$dev" -P "$port" -p "$toggle"Note that not all hubs implement the port power feature - but luckily I had an unused one laying around that does. Unfortunately, one of my lights won't spin unless the physical power switch on the light is toggled - hopefully that's not true for yours.
\- must appear. The hyphen-minus is the delimiter between the command name and one-line description.
.SH NAME foo-bar \- foos the template foo-what-barTypical mistakes regarding paragraphs Using a
.PP macro directly following a .SH or .SS macro is useless. This macro should be used between paragraphs:
.SH OPTIONS The program follows the usual GNU command line syntax, with long options starting with two dashes ( \-'). .PP A summary of options is included below.Options/File descriptions To describe options or files it s usually useful to make use of the
.TP macro.
.SH OPTIONS .TP .B \-f, \-\-force Force the execution of the specified command.
.SH FILES .TP .I ~/.foobar Per user configuration file.To create more than one intended paragraph the
.IP macro can be used.
.TP .B \-f, \-\-force Force the execution of the specified command. .IP This option has no effect in conjunction with \fB\-\-foo\fP.Avoid hyphenation in URLs/URIs/paths Usually we don t want URLs or URIs to be hyphenated. This can be done using the
\% sequence. Typical examples:
A short tutorial is available online at \fI\%http://foo.tld/some/path/here/manual.html\fP.
On a Debian system the complete text of the GNU General Public License version 2 can be found in the file \fI\%/usr/share/common-licenses/GPL\-2\fP.Referencing persons and their mail address The common markup is to write the person name in bold letters and the mail address in roman letters is put into angle brackets. It s usually a good idea to mark where the mail address starts and ends. We can use the
\& sequence as shown in the following example:
\fBDaniel Leidert\fP <\&daniel.leidert@wgdd.de\&>
Low-bandwidth
versions of the recorded talks are now available. There are currently
two exceptions:
*whew* I did a bunch of things yesterday. We took our kinderg rtner to her first Friday at her new school (and were about 10 minutes tardy. oops). We then took our toddler to a nearby playground with swings and slides and let her expend some energy. After she had been sufficiently exercised, we walked back home, stopping at a coffee shop on the way. The baristo (you call male baristas baristos, right? :) ) recognized my MC Frontalot shirt and asked whether I had caught him the previous weekend at PAX. Unfortunately, I have not attended PAX since 2006, but I *did* purchase the tee directly from The Front himself ;)
When we got home, I worked a bit on an English Language parser implementation and then went to the University of Washington to meet with Emily Bender about getting in to the Professional Master s program in Computational Linguistics. It all looks good, and I even got the good news that the GRE is no longer required!
After the meeting, I headed home and poked at the parser for a little while longer. I then picked Scarlet up from after-school care and brought her home. I then hopped in the car and drove toward Bellevue to meet up with Monty while he s in town. I over-estimated the amount of time traffic would steal on my way to Bellevue, and had an extra hour to blow. So I dropped by building 41 and shot the IronPython bull with Dino. It turns out he s got an android phone, too. I told him it was possible to put a debian chroot on it and that he should even be able to apt-get install ironpython to his phone soon ;) We talked briefly about the CodePlex Foundation and Sam Ramji s departure from The Evil Empire. Dino seems skeptical about the project. I don t have enough information to have much of an opinion. However, it sounds like some folks I trust are involved, so I m hopeful.
I left MS just in time to make it to the wrong address at the specified time. My phone had just enough juice to call Monty to get the right address and then use the navigation system to find my way there. I wasn t able to make reservations at the place we intended to go for dinner until 8:15, so we went to the Barnes & Noble for a bit. They only had one NLP book in stock and the examples are all in Python. I should learn that language one of these days As we were leaving the Pacific Place, Monty mentioned to me that he is on the advisory board for the CodePlex Foundation, and that they have been responsive enough to his input that they changed the Mission statement, at his recommendation, just one day before the Foundation was publicized. He feels that this is a very good direction for Microsoft to be heading.
My brother Chris was kind enough to watch the kids while we went out to dinner. Quick note: he recently graduated from UW with a BA in Electrical Engineering and is looking for work using his acquired knowledge, in case anyone needs one of those ;)
We met up with my wife, Hannah and our friends, Mike & Cynthia at our place. Monty graciously avoided mentioning the terrible state in which our apartment has recently found itself. The kids were super cute and polite and said hi/bye.
Over dinner we discussed building an android app (Monty has one, too ;) ) to automate the process of creating bounties for apps and getting folks to implement them. We also talked about MySQL and MariaDB, of course. Hannah and I recalled my time working for MySQL, Inc. on the MaxDB project and some subtle cultural differences we noticed while traveling. It was interesting getting the inside scoop about the Sun acquisition and some of the recent goings-on in the MySQL/Sun/Oracle world. I wasn t aware, for instance, that the EU is balking on the merger because of monopoly concerns.
Dear Lazyweb,
we re using gridengine 6.2 on our cluster system at work. On this system we have a queue for interactive jobs. The queue has a fixed number of slots. If someone wants to start an interactive session and no free slots are available the interactive job cannot start otherwise it will consume one slot during the session and free it again after the user quit the interactive session.
Unfortunately, if the user forgets to quit the interactive session properly (e.g. by entering quit in the terminal) and just closes the terminal, the interactive session becomes a zombie. The user cannot use this session anymore, but the process is still running and thus blocking a slot. Since it happens quite often that users fail to quit the interactive session properly, the free slots are used up pretty soon and no one can start new interactive sessions anymore quite a nice bug in the gridengine software (available in Debian/Lenny by the way )
You can see that those processes are still running using ps and qstat. The question is: how can I effectively search for those processes and kill them? Gridengine does not seem to be aware of those zombies and the user might run other interactive jobs in parallel which must not be killed. So how does one find the zombies and kill them reliably?
Site was down for almost a week, due to my provider being
DDoSed. Email was broken more so as SMTP was the target, but it was
rather odd that the data center decided to block outgoing SMTP
connections from a block of IPs, where my VPS is unfortunately a member
of.
I've since switched to a new provider. This makes my
third OpenVZ VPS, though I was meaning to move on to Xen.
At 6 US dollars a month though, it seems quite a bargain, so I'll have
to see where this goes.
The move also afforded me to change some stuff under the hood.
Apache is gone, replaced by nginx (although this required
having blosxom running under a thttpd backend, until I can
whip up a FastCGI equivalent.) BIND gave way to maradns,
cutting down significant memory usage. And dropbear replaces the
OpenSSH server. Exim 4 and dovecot remain though,
as they seem to quite big (or small) enough for my purposes.
I'll document more about the changes in later posts. In the meantime, I
need to catch up on emails and packaging...
Next.