Older blog entries for uweo (starting at number 17)

Back from vacation. 180 hours ago the world looked quite good. Now it's cold, rainy and dark. Oh well.
No, i don't mind rain. It's just that the rain is cold, which isn't really how i like it.
Oh well, i'll return some day. I liked the people.

I released ftpcopy-0.3.6 on tuesday and also update the strhash distribution. I also began to cleanup the udpserver code, but stumbled at the point where i had to update the documentation.

The problem is that pod is not good enough, texinfo can't generate manual pages. Let's sort the important points:

1. i'm not going to duplicate information. It's bad enough that code, --help output and documentation can get out of sync, anything more is just not acceptable.
2. any system i work on shall have all needed tools installed by default.
3. i want manual pages. They don't have to be perfect.
4. i want reasonable html output (this rules out pod).
5. i also like printed manuals.

I feel a temptation to write the documentation in texinfo and use a slightly modified man2html for the manual pages, but that's still not good enough.

It seems that i'm never satisfied with whatever solution i use for manuals. I started with ASCII text, then i used texinfo, tried a number of other documentation systems, went back to texinfo (using a number of wrappers around it, it didn't like umlauts back then), tried html, tried a number of html wrappers, want back to nroff / man, and finally i tried pod. Not a single solution lasted for more than a year.

Work hasn't been funny this week. I'm again at the point i've been in september and october, and that's alarming, meaning that i'm not feeling well here anymore (and judging from what i hear some other people share this feeling).
I'm tired of doing patchwork on other peoples projects, especially since i don't see any chance to finish my own stuff. I'm also tired of getting spam complaints. I'm tired of the misorganisation here. I'm tired of not having the wrench needed to assemble a 19'-rack (it's not the only tool missing).

Almost nothing happened at home. I'm tempted to move. But where to? Simple answer: somewhere near the coast (being able to reach the sea in less than 2.5 hours? Really tempting). But it seems that 99% of the job openings are in the other direction.

To make it short: I'm still totally demotivated and only waiting for the vacation to start, which will happen 2001-03-03.
I'm going to be _far_ away from any computer, i hope.

But still, there are promises to keep and things to be done:

• wrote the qmail-sendmail replacement, which just replaces the commandline sendmail emulation in the qmail package (in case you wonder: you almost certainly don't need it).
• released ftpcopy-0.3.5. There's no really important reason to update.
• released upgpverify-0.3.2 , a pgp/gpg filter for use in .qmail files. It checks the signature, decrypting if needed, and call's another program which can read de-mimed payload on a file descriptor. It shall replace the hackish pgp stuff used in the BBS (i remember having promised to replace that years ago).
• "released" (somewhat) cacco-0.4.0.tar.gz, a collection of tools to summarize cisco accounting files ("show ip accounting"). The documentation is pretty minimal. I packaged that just to keep a promise given almost 10 months ago.
  Besides it's quite a bit faster than the stuff my boss did.

I spent an evening trying to find out why lrzsz was unable to get stuff from a friends computer. It turned out that some piece of hardware at his site "compressed" a series of "@" bytes to just two "@" bytes. I really think his self-made internal communication system is at least a bit broken.

I didn't work on any piece of free software in december, without even noticing it. Motivation is everything, and i'm complete demotivated. Living in a building yard isn't really helpful, and that idiot of a worker who just entered the wrong room and moved a lot of papers into the dustbin ... well, to make it short, i still wonder what to do to him for that. It took me weeks to recover from that.

But the whois server was ready when he was needed (which was a few days later then planned, but that's ok). And it's used in two places by now, and seems to be _really_ stable (in both cases the source of support problems is identical to the source of the data, something which i'm no responsible for. Fortunately).

Released ftpcopy-0.3.4 and iodo-0.2.4 in january (the later is a collection of tools to create sockets and execute some other process, possibly under another user id).

fefe: of course size is important.

It's now three weeks without gas heating and water in my rooms (in all my rooms, though - i originally hoped to have water in the bath room).

Life is complicated.
Nothing happened on any free software project for quite a long time, until yesterday at least. It took some time to recover from that security hole: I was so sure that "too much trust" can't happen to me. The lesson hit me hard.

I actually learned something from it, and did some changes to the design of the whois server i started to write this week. Well, minor changes, fortunately.
Regarding whois server: the beast will possibly end up as GPL - $boss mentioned this (why he did it is a different story). Even after one week i still believe that the design is right, and apart from a few compatibility hacks to allow it to be used as a drop-in replacement at [unnamed COM-NET-ORG registrar] it will be quite nice (and even these hacks may be turned of).
I'd love to use a template system for the output, but that will not work out, too many things depend on the content of a record (at least that's the unfortunate situation at the registrar). I'm still undecided whether i'll include script language code in the output template, or create the complete output using a script language. [i tend to do the later, i don't need to parse templates that way].

Aside from that: I'm still living inside a building yard. The gas heating has been removed, and it will take 10 further days until the new one is installed (and even then things will get "funny": a low temperature boiler will then feed old time radiators). Right now it's somewhat cold in my rooms ...
Things will get worse: i'll not have water in the kitchen any longer. It will pay out in the long run, though.

A totally unrelated question: a friend of mine want's to install a VPN to my site. Nice idea, but i've a strong feeling that PPP over SSH isn't really a bright idea (my understand of TCP congestion control is that it isn't meant to be used over another congestion controlled media). He thinks it works, i think it _can't_ work with a loaded low-bandwidth link. Who is right, or where can i read more?

spot: please don't mention the daemons of /. I'd hate to see them getting busy here.

Released ftpcopy-0.3.3.

When i wrote the program i thought something like "why bother? It's me own FTP server anyway": I wrote the program to automatically copy files between 2 servers. When i re-read the code i thought the same. Later i decided to use it to mirror other servers, too, and even later i decided to make the code available to others ...
When i read about the scp security hole on bugtraq i suddenly *knew* where to look into.

The lesson? Don't allow bad code to exist, even for internal use.

The good news: My caffeine addiction seems to wear off. I was really, really tired on saturday and sunday, but i'm beginning to feel better again. No coke, no tea for almost 100 hours ...
I didn't get a caffeine addiction for three years, up to 2000-07. But then the stress level increased drastically, and i, once again, was stupid enough to let work get too much influence on my life.

The bad news: i detected a security problem in ftpcopy. No buffer overrun, no printf/syslog hole: "too much trust in the FTP server". Damned.

The telekom installed the TAE for the DSL line on monday. Today QSC installed the DSL pipeline. It even worked ... 144kbit isn't bad.
The provider didn't get the hint on the IP address application (n IP address _plus_ firewall, so an additional /30 or a DSL pipe in bridge mode would have been perfect), but proxy arp is fine for this situation, so i went that way.

Changing the IP addresses of five machines was an interesting experience. If my customers told me that changing IP addresses is beyond them for some reason or couldn't be finished in the next few months ... in short, i really didn't believe them. Now it do.
Change IP addresses. Change main filter. Change DNS server address. Change multiple application and server configurations. Change multiple access lists (host.allow, tcpservers configuration). Tell the outside world about the change. Fix multiple access lists there. Fix a number of ssh configurations or authorized_keys since the reverse mapping is not working now. Detected an overly long /etc/hosts on one machine. It's quite late now.
I still have to move my brothers machine to the new address, but that can wait until he notices that something is broken.

Anyway, i'm quite happy about that. Seing that the telekom get's something right at the first time is delightful.

On the free software front not much has happened. I finished the basic design of the trouble ticket system. The only thing i left out was indexing - i'll first look at which kind of queries will be needed and then decide how to do that. Actually, this thing begins to interest me, and so the coding was quite easy (still unfinished).

The patch is now where it should have been: klogd_lose.patch.
Sorry.

I looked at a number of trouble ticket and bug tracking systems in the last two days. To put it mildly: they all lack.
I'm astonished that the majority of them, especially the newer ones, are web-based. Hey, people, get a clue:

• discussions with clients is best done through email.
• email has lower turnaround times.
• if done correctly email is more secure, especially if you don't use passwords. [use a one-time key for each trouble ticket, and let the customer decide with whom he wants to share this]. This obviously isn't that important in for open source bug tracking.

Well, maybe it's just me, but i don't want to use a web browser to update the state of a ticket after i resolved the thing together with the customer. I just want to set the state to resolved in the last mail i send.
Apart from that email is just more easy - to use and to program processors for.

And all i've seen seem to be a bit unflexible. I'm not going to introduce different task-systems for company hotline (non-software customers), software customer support and developers internal stuff. My cow-orkers would kill me before i finish the sentence, i think.
In other words: the basic design has to be very, very simple, but extensible.

There is nothing wrong with having a web interface (aside from the simple fact that i will not use it if i don't need to use it), but being forced to use one? Heck, no.
And you can't easiely put something else about a web interface, but you can create some kind of web interface for almost everything without too much work.

I also went through my personal todo list:

1. BBS software: decided to not work on it anymore. Not even bug fixing. It's not something i want to continue working on. I wouldn't design it like this, and the basic design is from 1988 or so (and the UI is even older). Period.
2. gateway: will rewrite it. The basic design is still ok, but i' m a better coder today, and have learned a few lessons. Beside that: I now have some libraries with i didn't have in 1993, and they _will_ make the thing more beautiful. But the change is quite fundamental, and anyway, the best way to get rid of bloat and historical workaround in code is to rewrite it.
   Schedule: don't know.
3. utftpd: i'll rewrite it. The configuration file language is fine, except there shouldn't be a configuration file language at all. Yeah, it's highly flexible. And this is not needed.
   I'll keep the one client, one TFTP server process design for now, but will cleanup the server if i happen to find something which wouldn't work in a single server design. I'm still unsure whether multicast TFTP is useful. Mind you, utftpd has been written to backup my router configuration files.
   Schedule: This year.
4. udpserver: decided to finish it. I need something like this to start the TFTP server.
   Schedule: Soon.
5. syslog server: decided to finsish it. I do not really need it, (except that linux sysklogd is horrible), but a clean and reliable implementation of a syslog daemon which doesn't fill the disk is worthwhile. [takes and translates network input, sends it to multilog]
   Schedule: Soon. What needs to be done is to write a useful configuration tool.
   Originally i didn't ever want to use it one any other machine then the log server at my workplace, but now i think this software might be useful for others, too.
   • speaking of linux sysklogd: That hack _still_ loses if the syslogd is restarted. I sent a fix for that to the authors / maintainers in 1996 and 1998. See this patch. Shall i be amused?
6. lrzsz v1: i'm tempted to remove all traced of internationaliation from lrzsz. gettext _still_ is at version 0.10.35, and still throws out that annoying warning that messages must not contain \r (which is wrong, btw). I would also get rid of a number of bugs in Makefile.in.in, of which the wrong usage or not-usage of DESTDIR is the most annoying. And building the package on a machine without GNU make will then be possible.
   No, i'm not volunteering to maintain gettext.
   Schedule: Still undecided.
   • in case you wonder: my personal build environment disencourages warnings. It's quite annoying to get them mailed twice a day.

7. lrzsz v2: Will possibly finish writing X/Ymodem sender and receiver tools this year. I'm not happy about the sender state machine now, it works, but it looks ugly. This needs more thinking.
   The Zmodem state machine will get even more ugly. I need to re-read a few descriptions of the protocol first.
8. watchdog: the watchdog software the company uses now could benefit from a cleanup. It now runs for more than 6 months, and all the problems with the design should have shown up by now. Actually quite a number did show up, and the ad-hoc changes not only made the code messy, but desynchronized code and documentation.
   Schedule: This year.
   Mostly easy stuff, but the scheduler ... at the moment the interval of 300 seconds is fixed. I should get rid of this, for cleanness sake. Oh, and i need to convince the boss to release it under GPL. Should be easy.
9. conflib:
   support discontinued. I don't use it anymore.
10. ftpcopy:
    i will implement some kind of "move" functionality -

           ftpcopy ftp://re.mo.te/ ./re.mo.te/
    
           (cd re.mo.te ; find . -type f -print0) | xargs -0
    
    
               ftpdelete ftp://re.mo.te/ 
    

    Not using -print0 is also possible. Files with \n inside the file name are then just not deleted. (i suspect that the are impossible to download anyway).

Netscape eats an astonishing amount of memory now. Oh, well. Maybe i should start to post with some other tool.