Agrégateur de flux

Apparently (hi Zhenech, found on Plänet Debian), a Man does not only need to fork a child, plant a tree, etc. in their life but also write a DynDNS service. Perfect for opening a new tag in the wlog called archæology (pagetable.com – Some Assembly Required is also a nice example for these).

Once upon a time, I used SixXS’ heartbeat protocol client for updating the Legacy IP (known as “IPv4” earlier) endpoint address of my tunnel at home (My ISP offers static v4 for some payment now, luckily). Their client sucked, so I wrote on in ksh, naturally.

And because mksh(1) is such nice a language to program in (although, I only really begun becoming proficient in Korn Shell in 2005-2006 or so, thus please take those scripts with a grain of salt, I’d do them much differently nowadays) I also wrote a heartbeat server implementation. In Shell.

The heartbeat server supports different backends (per client), and to date I’ve run backends providing DynDNS (automatically disabling the RR if the client goes offline), an IP (IPv6) tunnel of my own (basically the same setup SixXS has, without knowing theirs), rdate(8) based time offset monitoring for ntpd(8), and an eMail forwarding service (as one must not run an MTA on dynamic IP) with it; some of these even in parallel.

Not all of it is documented, but I’ve written up most things in CVS. There also were some issues (mostly to do with killing sleep(1)ing subprocesses not working right), so it occasionally hung, but very rarely. Running it under the supervise of DJB dæmontools was nice, as I was already using djbdns, since I do not understand the BIND zone file format and do not consider MySQL a database (and did not even like databases at all, back then). For DynDNS, the heartbeat server’s backend simply updated the zone file (by either adding or updating or deleting the line for the client) then running tinydns-data, then rsync’ing it to the djbdns server primary and secondaries, then running zonenotify so the BIND secondaries get a NOTIFY to update their zones (so I never had to bother much with the SOA values, only allow AXFR). That’s a really KISS setup ☺

Anyway. This is archæology. The scripts are there, feel free to use them, hack on them, take them as examples… even submit back patches if you want. I’ll even answer questions, to some degree, in IRC. But that’s it. I urge people to go use a decent ISP, even if the bandwidth is smaller. To paraphrase a coworker after he cancelled his cable based internet access (I think at Un*tym*dia) before the 2-week trial period was even over: rather have slow but reliable internet at Netc*logne than “that”. People, vote with your purse!

I usually try to avoid administering printers whenever possible. As a result I end of flailing around the CUPS web interface before I figure out how to re-enable a printer. And, when I get a call to help debug a printer, I can't easily tell people what to do.

When I try to do what I need via the command line, I end up spending at least 10 or 15 minutes re-reading man pages before I piece together the steps.

Here's my attempt to document the steps so I don't have to re-read man pages.

Setup

In these examples, the printer name in question is: stability and it is a network printer, with local DNS that properly resolves the hostname stability to an IP address.

The cups commands in these examples can be run as a non-root user if that user is in the lpadmin group.

Type:

groups

To see if lpadmin is listed. If not:

sudo adduser <your-user-name> lpadmin

Then, to gain access to the new group without logging out and logging in again:

newgrp lpadmin Network access

First, try to ping the printer:

ping stability

If this fails, restart the printer and/or check network cables. No point in doing anything else until it responds to pings.

Can't submit new jobs to the printer

Next, if the problem is that the printer is greyed out when you try to print a document or your application tells you that the printer is rejecting jobs, confirm this status with:

lpstat -a stability

It will either output:

stability accepting requests since Mon 20 May 2013 10:28:57 AM EDT

Or

stability not accepting requests since Mon 20 May 2013 10:28:57 AM EDT - Rejecting Jobs

If it is rejecting jobs, try:

/usr/sbin/cupsaccept stability Accepts new jobs, but just doesn't print

On the other hand, if the printer is accepting jobs, but the jobs are not printing, find out if the printer is enabled with:

lpstat -p stability

You should get either:

printer stability is idle. enabled since Mon 20 May 2013 10:28:57 AM EDT

Or:

printer stability disabled since Mon 20 May 2013 10:35:10 AM EDT - Paused

If it is disabled, you should first see what queued jobs there are:

lpq

If you have a list of duplicate pending jobs, be sure to delete the duplicates to avoid having your print job come out multiple times.

To delete a queued job, type the following (n should be the number in the Job column of the lpq output):

cancel <n>

After you have deleted duplicate jobs, try "enabling" it:

/usr/sbin/cupsenable stability

Then, re-rerun the lpq command and see if it's now "ready." At this point, the jobs should start printing.

Review of concepts

For review... a few important concepts:

• cupsaccept/cupsreject: controls whether a printer will accept or reject new jobs. It doesn't matter whether the printer is enabled or disabled.
• cupsenable/cupsdisable: controls whether a printer will print existing jobs. It doesn't matter whether the print is accepting or rejecting new jobs.

Drupal websites don't always need to allow users to register themselves with an account. This site doesn't, for instance. Anonymous commenting is turned on. The contact form is enabled for anonymous users. And those are the only thing that any member of the public would need to do - other than read. So nobody needs to set themselves up with a login. … Read more about Useful modules: Spambot

Blog Category: TechnologyDrupal Planet

I want to thank the good folks at ThinkShout and ZivTech for organizing the Drupal DoGooders Happy Hour to benefit my family and me, as well as giving people attending DrupalCon an opportunity to hang out and have some drinks. Even though I will not be in Portland this week, I plan to be present in spirit, beginning with a virtual appearance there. Join the crew this evening (May 20) at about 4:00 PDT to raise a glass in toast of doing Drupal Good and for a quick Q & A with me beginning about 4:30.

What a long strange trip it's been.

From Sunnyvale in 2007 when I conceived the Embedded Media Field module, to Boston DrupalCon in 2008, where I presented my first State of the Media session, to DC in 2009 where we launched the Media sprint supporting the Media suite of modules, to Chicago 2011 and Denver 2012.

These are the fun times that I recall fondly, doing good with my fellow cohorts. And by doing good, I mean really doing good things. Because where else in the business world can you spontaneously form a group of competitors, build something awesome, and give it freely to the rest of the world?

I'm really going to miss that this year. I mean that even though I continue to contribute to Drupal whatever and whenever I can, I am going to miss seeing you guys this year. There is a magic that happens when you get three or more Drupalers together in the same room. But circumstance has had its way with me these past two years and until we have a DrupalCon "Three Mile Island", I will have to be content with a virtual appearance.

So, join me on Monday evening to see my Stephen Hawking impersonation.

read more

It’s that time again. Drupalcon is about to kick off and it’s the biggest one yet. Over 3300 Drupalers from across the globe will meet in Portland tomorrow to delve into one of the fastest growing open source technologies in the world.

And ImageX will be there loud and clear. As Gold Sponsors of the conference, we’re building on our commitment to give back. Members of our team will be presenting in sessions, participating in birds of a feather groups, co-hosting an after party with Mediacurrent and taking part in code sprints to help support and grow Drupal.

It’s that time again. Drupalcon is about to kick off and it’s the biggest one yet. Over 3300 Drupalers from across the globe will meet in Portland tomorrow to delve into one of the fastest growing open source technologies in the world.

And ImageX will be there loud and clear. As Gold Sponsors of the conference, we’re building on our commitment to give back. Members of our team will be presenting in sessions, participating in birds of a feather groups, co-hosting an after party with Mediacurrent and taking part in code sprints to help support and grow Drupal.

Occasionally, someone asks me whether we should encourage use of the --ask-cert-level option when certifying OpenPGP keys with gpg. I see no good reason to use this option, and i think we should discourage people from trying to use it. I don't think there is a satisfactory answer to the question "how will specifying the level of identity certification concretely benefit anyone involved?", and i don't see why we should want one.

gpg gets it absolutely right by not asking users this question by default. People should not be enabling this option.

Some background: gpg's --ask-cert-level option allows the user who is making an OpenPGP identity certification to indicate just how sure they are of the identity they are certifying. The user's choice is then mapped into four levels of OpenPGP certification of a User ID and Public-Key packet, which i'll refer to by their signature type identifiers in the OpenPGP spec:

0x10: Generic certification

The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID.

0x11: Persona certification

The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified.

0x12: Casual certification

The issuer of this certification has done some casual verification of the claim of identity.

0x13: Positive certification

The issuer of this certification has done substantial verification of the claim of identity.

Most OpenPGP implementations make their "key signatures" as 0x10 certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types.

By default (if --ask-cert-level is not supplied), gpg issues certificates ("signs keys") using 0x10 (generic) certifications, with the exception of self-sigs, which are made as type 0x13 (positive).

When interpreting certifications, gpg does distinguish between different certifications in one particular way: 0x11 (persona) certifications are ignored; other certifications are not. (users can change this cutoff with the --min-cert-level option, but it's not clear why they would want to do so).

So there is no functional gain in declaring the difference between a "normal" certification and a "positive" one, even if there were a well-defined standard by which to assess the difference between the "generic" and "casual" or "positive" levels; and if you're going to make a "persona" certification, you might as well not make one at all.

And it gets worse: the problem is not just that such an indication is functionally useless; encouraging people to make these kind of assertions actively encourages leaks of a more-detailed social graph than just encouraging everyone to use the default blanket 0x13-for-self-sigs, 0x10-for-everyone-else policy.

A richer public social graph means more data that can feed the ravenous and growing appetite of the advertising-and-surveillance regimes. i find these regimes troubling. I admit that people often leak much more information than this indication of "how well do you know X" via tools like Facebook, but that's no excuse to encourage them to leak still more or to acclimatize people to the idea that the details of their personal relationships should by default be public knowledge.

Lastly, the more we keep the OpenPGP network of identity certifications (a.k.a. the "web of trust") simple, the easier it is to make sensible and comprehensible and predictable inferences from the network about whether a key really does belong to a given user. Minimizing the complexity and difficulty of deciding to make a certification helps people streamline their signing processes and reduces the amount of cognitive overhead people spend just building the network in the first place.

Finally, just in time for the DrupalCon we got a first fluxkraft preview version out of the door!

It's not feature complete and does not implement any UI improvements or workflows yet, but the flux-engine is there and working.

You may not know this, but I am a huge PowerDNS fan. This may be because it is so simple to use, supports different databases as backends or maybe just because I do not like BIND, pick one.

I also happen to live in Germany where ISPs usually do not give static IP-addresses to private customers. Unless you pay extra or limit yourself to a bunch of providers that do good service but rely on old (DSL) technology, limiting you to some 16MBit/s down and 1MBit/s up. Luckily my ISP does not force the IP-address change, but it does happen from time to time (once in a couple of month usually). To access the machine(s) at home while on a non-IPv6-capable connection, I have been using my old (old, old, old) DynDNS.com account and pointing a CNAME from under die-welt.net to it.

Some time ago, DynDNS.com started supporting AAAA records in their zones and I was happy: no need to type hostname.ipv6.kerker.die-welt.net to connect via v6 — just let the application decide. Well, yes, almost. It’s just DynDNS.com resets the AAAA record when you update the A record with ddclient and there is currently no IPv6 support in any of the DynDNS.com clients for Linux. So I end up with no AAAA record and am not as happy as I should be.

Last Friday I got a mail from DynDNS:

Starting now, if you would like to maintain your free Dyn account, you must now log into your account once a month. Failure to do so will result in expiration and loss of your hostname. Note that using an update client will no longer suffice for this monthly login. You will still continue to get email alerts every 30 days if your email address is current.
Yes, thank you very much…

Given that I have enough nameservers under my control and love hacking, I started writing an own dynamic DNS service. Actually you cannot call it a service. Or dynamic. But it’s my own, and it does DNS: powerdyn. It is actually just a script, that can update DNS records in SQL (from which PowerDNS serves the zones).

When you design such a “service”, you first think about user authentication and proper information transport. The machine that runs my PowerDNS database is reachable via SSH, so let’s use SSH for that. You do not only get user authentication, server authentication and properly crypted data transport, you also do not have to try hard to find out the IP-address you want to update the hostname to, just use $SSH_CLIENT from your environment.

If you expected further explanation what has to be done next: sorry, we’re done. We have the user (or hostname) by looking at the SSH credentials, and we have the IP-address to update it to if the data in the database is outdated. The only thing missing is some execution daemon or … cron(8). :)

The machine at home has the following cron entry now:

*/5 * * * * ssh -4 -T -i /home/evgeni/.ssh/powerdyn_rsa powerdyn@ssh.die-welt.net

This connects to the machine with the database via v4 (my IPv6 address does not change) and that’s all.

The machine with the database has the following authorized_keys entry for the powerdyn user:

command="/home/powerdyn/powerdyn/powerdyn dorei.kerker.die-welt.net" ssh-rsa AAAA... evgeni@dorei

By forcing the command, the user has no way to get the database-credentials the script uses to write to the database and neither cannot update a different host. That seems secure enough for me. It won’t scale for a setup as DynDNS.com and the user-management sucks (you even have to create the entries in the database first, the script can only update them), but it works fine for me and I bet it would for others too :)

0 comment(s) | this blog is flattr enabled

Or rather, hello Planet!

Here’s a somewhat traditional introductory post.

I’m Nicolas Dandrimont, I’m French, I’m sysadmin in a grande école, where I’m mostly in charge of the GNU/Linux workstations and servers.

In Debian, I’m a DM, currently in the NM queue, so I might become a DD soon-ish. I am (rather inactively) co-maintaining a few packages. In my Debian “career”, I have been involved in OCaml packaging and Python packaging, although lately most of my time has been spent on Google Summer of Code (mentor for two mentors.debian.net projects in 2012, org admin for Debian in 2013), and on mentors.debian.net.

In other free-software related projects, I own a RepRap 3D printer, and I grew some interest in the related software, e.g. Slic3r and printrun. There have been a lot of action in Fedora about packaging 3D-printing-related software, and it’d be great to get a team together to work on that in Debian during the jessie release cycle. Consider this a call for interested parties

Unrelatedly, paultag has tricked me into working on hy, which is way too much fun. Blame him if you feel that I have been inactive lately, this has been eating way too much of my free time

Hopefully I’ll be able to make regular updates on the work I do in Debian and free software, so stay tuned!

besides working on the preparation of the Perl 5.18 transition, I also looked into some RC bugs:

• #542564 – xmlroff: "xmlroff: uses libgnomeprint which is scheduled for removal"
  drop build dependency and disable in ./configure, upload to DELAYED/2
• #665506 – src:ario: "ario: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2, overriden by a faster upload of another bug squashing DD
• #665530 – src:getstream: "getstream: Including individual glib headers no longer supported"
  add patch from Michael Biebl, upload to DELAYED/2
• #665555 – src:gxine: "gxine: Including individual glib headers no longer supported"
  add info about next build failure to bug report
• #665573 – src:librcc: "librcc: Including individual glib headers no longer supported"
  include patch from Colin Watson, upload to DELAYED/2
• #665579 – src:meanwhile: "meanwhile: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2
• #665609 – src:sagasu: "sagasu: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2
• #665628 – src:xmlroff: "xmlroff: Including individual glib headers no longer supported"
  apply patch from Michael Biebl, upload to DELAYED/2
• #707686 – dhelp: "dhelp: FTBFS and uninstallable in sid: needs ruby-gettext"
  upload last week's patch to DELAYED/2
• #708598 – src:libgeo-ip-perl: "libgeo-ip-perl: FTBFS: CAPI must be at least 1.4.8 - Please update"
  upload new upstream release (pkg-perl)
• #708730 – libanyevent-perl: "libanyevent-perl: architecture specific constants in an arch:all package (again)"
  switch back to arch:any (pkg-perl)
• #708766 – libimager-qrcode-perl: "libimager-qrcode-perl: Update for newer libimager-perl needed"
  file a bug with patch (update for newer libimager-perl)

Today, I played at TC Cantincrode in Mortsel, Belgium, in the first round. This is the first year I'm playing tennis competitively, so I wasn't expecting to win by a pretty wide margin. Now while I didn't win, the margin wasn't as wide as I'd expected; 6/4 - 6/3 isn't too bad for the non-ranked beginner that I am. For comparison: I lost my previous match with 6/2 - 6/0, and I was not unhappy about that.

Part of this was due to my opponent (by his own admission) not playing his best; but still, I'm quite happy about my result here.

My next match probably won't be as good. Oh well.

I use RSS feeds to keep up with academic journals. Because of an undocumented and unexpected feature (bug?) in my (otherwise wonderful) free software newsreader NewBlur, many articles published over the last year were marked as having been read before I saw them.

Over the last week, I caught up. I spent hours going through abstracts and downloading papers that looked interesting or relevant to my research. Because I did this for hundreds of articles, it gave me an unusual opportunity to reflect on my journal reading practices in a systematic way.

On a number of occasions, there were potentially interesting articles in non-open access journals that neither MIT nor Harvard subscribes to and that were otherwise not accessible to me. In several cases where the research was obviously important to my work, I made an interlibrary request, emailed the papers’ authors for copies, or tracked down a colleague at an institution with access.

Of course, articles that look potentially interesting from the title and abstract often end up being less relevant or well executed on closer inspection. I tend to cast a wide net, skim many articles, and put them aside when it’s clear that the study is not for me. This week, I downloaded many of these possibly relevant papers to, at least, give a skim. But only if I could download them easily. On three or four occasions, I found inaccessible articles at this margin of relevance. In these cases, I did not bother trying to track down the articles.

Of course, what appear to be marginally relevant articles sometimes end up being a great match for my research and I will end up citing and building on the work. I found several suprisingly interesting papers last week. The articles that were locked up have no chance at this.

When people suggest that open access hinders the spread of scholarship, a common retort is that the people who need the work have or can finagle access. For the papers we know we need, this might be true. As someone with access to two of the most well endowed libraries in academia who routinely requests otherwise inaccessible articles through several channels, I would have told you, a week ago, that locked-down journals were unlikely to keep me from citing anybody.

So it was interesting watching myself do a personal cost calculation in a way that sidelined published scholarship — and that open access publishing would have prevented. At the margin of relevance to ones research, open access may make a big difference.

In Drupal there are many different methods to turn long forms into multipage/multistep forms. The most known one is perhaps the great ctools module or even custom solutions using Drupal’s form API. However as you may agree with me none of these solutions are really that easy, specially when it comes to Ajax. Therefore many developers in Drupal community tried or still trying to find an even easier method. What I’m going to introduce to you is yet another magical method :).

read more

I have a Raspberry Pi running Raspbian (wheezy) with a UVC camera available as /dev/video0.

I've been trying for three weeks to live-stream the picture from the camera onto the local network. I have tried crtmpserver and vlc, read several dozens of how-tos, but so far I have not been able to get a streaming setup working, no matter what I tried.

Hence my plea to the lazy web: does anyone have such a setup running on top of Debian? Would you please let me know how you did it?

Thanks a lot!

NP: Eels: End Times

All recent articles on packaging using a version control system should really appear over at Planet vcs-pkg. Feel free to just ping me with a feed URL that is vcs-pkg-specific.

Steps to build your responsive drupal 7 theme

1) Understand your design and decide on the breakpoints.

2) Start with your theme info file

I've written an article as monthly one, "Debian Hot Topics", and  this time, teaching steps and ways that how to put packages to Debian official repository. Japanese readers, have fun :)

We’ll be at DrupalCon Portland next week and we’d like to share some of our DrupalCon plans. In brief summary, we’re excited to announce that we’re co-training on Drupal Commerce with Commerce Guys, and we’re continuing the conversation we started last month about Long Term Support for Drupal 6.

Interested? Read on.

read more

Drupal Commerce 1.x has had a full release for a year and a half. We rolled the initial full release at DrupalCon London, and since then we've put out a few of minor releases to fix bugs, add minor features, and touch up its APIs.

Since that time we've also fielded requests for a 2.x branch with increasing regularity but have postponed the matter until Drupal 8 itself settled down some. Drupal Commerce 1.x was developed when Drupal 7 was still in its unstable release phase on top of incomplete Views, Entity API, and Rules modules. While some contributors were eager to dive into a fresh branch of Drupal Commerce that allowed major API changes and rewrites, we weren't exactly eager to reproduce the effort of developing a major contributed Drupal module on such an unstable foundation.

However, in order to be ready to take full advantage of the new features and modules in Drupal 8, we met last year to draw up a roadmap for Drupal Commerce 2.x. The roadmap provides:

1. An overview of our primary goals - re-architect around the new Drupal 8 systems where appropriate and mitigate the challenges users and developers have faced with Drupal Commerce 1.x,
2. A list and description of our major development emphases and how they will affect various systems in core Drupal Commerce,
3. And a task list of specific changes we're either contributing to in Drupal 8 or expecting to make to Drupal Commerce itself.

I'll be presenting the roadmap at DrupalCon Portland and am looking forward to getting busy with the code. As development progresses, we'll keep the roadmap up to date.

Check out the roadmap to see where you can get involved today.