Skip to main content

Ralsina.Me — Roberto Alsina's website

Annoying APIs: djbdns

Look­ing for a sim­ple way to lookup the MXs for a giv­en do­main, I ran in­to lib­d­jbdns. Which has a de­light­ful­ly sim­ple API.

Of course it has its wrin­kles.

Con­sid­er the MX lookup in­ter­face:

dns_mx(&out,&fqdn);

Where out and fqdn are stral­locs (a sort of string that can con­tain 0).

But just try pars­ing out! Here's the ex­pla­na­tion:

Each MX record is a two-byte MX dis­tance fol­lowed by a 0-ter­mi­nat­ed dot-en­cod­ed do­main name. If the do­main does not ex­ist in DNS, or has no MX record­s, out will be emp­ty.

Be­cause al­most noone us­es MX dis­tances high­er than 256, sad­ly, this usu­al­ly looks like this (sor­ry for the no­ta­tion ;-)

\0 10 f i r s t . m x \0 \0 20 s e c o n d . m x

So, you can not split on the NULLs be­cause there are NULLs in the dis­tances.

Which is not hard to parse, but is def­i­nite­ly more an­noy­ing than it should be. How hard would it be to re­turn an ar­ray of struct­s?

CMake is nice. Or not?

I am play­ing with CMake. Specif­i­cal­ly, I am try­ing to re­place the sim­plis­tic hand­made Make­files for my RA-­Plu­g­ins projec­t.

The parts about de­tect­ing li­braries and con­di­tion­al­ly com­pil­ing plug­ins based on what you have were sur­pris­ing­ly easy!

Un­til I ran in­to ... man pages.

Here is a Make­file that would build all the man­pages for the plu­g­in­s:

MANPAGES=plugins-ra.8 authchecks.8 rcptchecks.8
man: \$(MANPAGES)
%.8: %.man.txt
      txt2man -t \${basename $< .man.txt} < $< > $@

As you can see... triv­ial. All I need to do in or­der to add a man page is add what­ev­er.8 to the list, and it will be cre­at­ed from what­ev­er.­man.tx­t.

But... how does one do that us­ing CMake?

I start­ed think­ing of us­ing a FILE (GLOB *.­man.tx­t) and then a FORE­ACH over that, and then... then what? Re­al­ly, I am stumped. I am a new­bie, though, and get­ting the big, dif­fi­cult stuff done is enough to switch. I should gen­er­ate these be­fore dis­tri­bu­tion any­way.

So, I wrote a wee Make­file.­man­pages and added this for CMAKE:

ADD_CUSTOM_TARGET ( manpages make -f Makefile.manpages )

But I am cu­ri­ous about find­ing the cmakeish way.

Misterious referrer

For some rea­son, there seems to be an im­age, some­where in this site, that gets a bazil­lion hits from google's im­age search.

I have no idea what im­age it is, or why it is sought.

Since stat­counter trun­cates the re­fer­rers, and it seems to be on many many pages... it's just weird.

For some rea­son, a do­main in some lan­guage I don t speak (n­joyschool.net) seems to be in­volved...

Here's some ex­am­ple re­fer­rers:

images.google.at/imgres?imgurl=http://www.njoyschool.net/data-new/
club/bbs033/sorry.gif&imgrefurl=//ralsina.me/
lateral/sto

images.google.dk/imgres?imgurl=http://www.njoyschool.net/data-new/
club/bbs033/sorry.gif&imgrefurl=//ralsina.me/
lateral/sto

images.google.co.ma/imgres?imgurl=http://www.njoyschool.net/data-new/
club/bbs033/sorry.gif&imgrefurl=//ralsina.me/lateral/

Any­one has any idea what the heck those are? They are al­most all I got in my re­fer­rers log!

Linux and a TrendNet TEW-PC16

So, I am try­ing to use this an­cient card with Lin­ux and all I get when I plug it is a mes­sage in the logs:

Aug  3 13:11:28 monty cardmgr[12752]: unsupported card in socket 0
Aug  3 13:11:28 monty cardmgr[12752]:   product info: "PCMCIA", "11M WLAN Card", "", ""
Aug  3 13:11:28 monty cardmgr[12752]:   manfid: 0x0274, 0x1601  function: 6 (network)
Aug  3 13:11:44 monty cardmgr[12752]: exiting

A lit­tle dig­ging showed me the fol­low­ing:

  1. This card is sup­­posed to work with the hostap driv­er

  2. It has nev­er been a pop­u­lar card.

  3. Noone seems to have used the thing on Lin­ux. Or if they did, they nev­er doc­u­­men­t­ed it.

So... all you have to do is in­form the PCM­CIA thing in Lin­ux that this card works with hostap.

After you installed hostap correctly for your kernel, edit /etc/pcmcia/hostap_cs.conf and add this:

card "TrendNet TEW PC16"
   manfid 0x0274, 0x1601
   bind "hostap_cs"

Re­boot (or restart the pcm­cia ser­vice, un­plug, plug, etc), and that's it.

Fixing windows the unixy way

A while ago, I wrote about my mis­ery try­ing to use a HP PSC 1410 print­er at­tached to a XP box as a net­work print­er.

Ba­si­cal­ly:

  • The Lin­ux driv­er freezes the print­­er if you print re­­mote­­ly (but works lo­­cal­­ly)

  • The ba­sic win­­dows driv­er will not even in­­stall on a Win­­dowsMe note­­book with 32MB of RAM (says it re­quires 128MB and clos­es)

  • The full fea­­tured driv­er re­quires the print­­er to be lo­­cal­­ly con­nec­t­ed to in­­stall suc­ces­­ful­­ly. And if you do that, you can't lat­er tell it that the print­­er is re­­mote (plus it in­­stalls about 600MB of garbage)

Since at­tach­ing the print­er to the lin­ux box and us­ing PS driv­ers was not prac­ti­cal (be­cause it has to be used as a scan­ner too...what­ev­er), I thought... wait a sec­ond. Why not do that on win­dows?

And what the hel­l, it worked.

If you have a rebel can't be net­worked print­er, do this and be sor­ta hap­py. It ex­plains how to cre­ate a Ghostscrip­t-based vir­tu­al print­er that you can share.

And of course, the client PS driv­ers works just fine on any OS. Which means you can use print­ers that, for ex­am­ple, have no Lin­ux driv­ers. Or no Win­dows9x/Me/NT driv­ers.

On­ly prob­lem re­al­ly is that it's a bit slug­gish (it may wait a minute or two be­fore it prints) be­cause the XP box is slow... but it beats copy­ing files.


Contents © 2000-2020 Roberto Alsina