WEBlog -- Wouter's Eclectic Blog

View comments on this entry (1 comment)...

Thu, 06 Aug 2009

Re:

I recently (some of it during debconf, some of it right after) blogged a few things that are, shall we say, controversial. Obviously I got some response to that. Since I haven't replied individually to most of those replies, I thought a new blog post would work well.

On my very short and rather unconstructingly hateful post about gnome-keyring, JanC wrote:

I can understand why you would get popups from seahorse-agent if you use that, but if ssh gives you popups from gnome-keyring, that sounds like something is misconfigured to me?
BTW: it's easy to configure things in such a way that seahorse-agent doesn't get used inside a terminal; it's just another ssh-agent after all...

Well, presumably. But I didn't do it.

wouter@celtic:~/data/blog/live/en/computer$ sudo dpkg-divert --list|grep gnome
Password: 
local diversion of /usr/bin/gnome-power-manager to /usr/bin/gnome-power-manager-sucks
local diversion of /usr/bin/gnome-keyring-daemon to /usr/bin/g-k-sucks
wouter@celtic:~/data/blog/live/en/computer$ svn up

** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success

** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success

** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success

** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success

** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success

** (process:10384): WARNING **: couldn't communicate with gnome keyring daemon via dbus: Failed to execute program /usr/bin/gnome-keyring-daemon: Success
At revision 1086.
wouter@celtic:~/data/blog/live/en/computer$

Note particularly the fact that the login works perfectly okay right after whatever causes this finally gives up trying to call gnome-keyring, and svn finds the authentication info in its config file (this is my blog. Not as if there's anything of serious security there; those repositories that are important are behind SSH)

I never even asked anything to run gnome-keyring-daemon; but if I allow svn to do its thing without asking, this is what happens. I don't have libpam-gnome-keyring installed, and I'm no longer running gdm; two sources of things that run gnome-keyring-daemon without my asking. Yet the bloody thing keeps cropping up everywhere I look. It is broken, and it should not exist. Thank god for dpkg-divert.

On my post about MS and the GPL, some people wrote that Microsoft only published the code for GPL compliancy, not because they thought it a good idea or some such.

While this might be true, the fact of the matter is that, unlike many many many other companies out there, they decided to not just put a blob of code on their website and be done with it, but instead to do the right thing, and get the code merged. That is far beyond what the GPL requires them to do, and it signals to me that they did this because they are changing—the Microsoft of 10 years ago wouldn't even have written those drivers in the first place, let alone get them merged. That, I think, was the most important point of that post.

On my post about passwords, Matthew Johnson wrote:

An SSH key is very much not just "a password written down". Passwords are sent in the clear (inside the tunnel) and are therefore more subject to MITM attacks, keyloggers, etc. SSH keys, because of the asymmetric crypto, if you do manage an MITM attack using an SSH key does not reveal anything which could be used to authenticate another time.

Good point; I overlooked that. Yes, that does make passwords somewhat less secure, and defeats most of what I said. However, it does not defeat the fact that allowing only one way to login increases the chance that you will require some people to jump through hoops—me, I do not keep my SSH keys on my laptop's hard disk, so they don't get compromised should the laptop ever get stolen. That does make it harder for me to log on to a system using these keys, however, and it makes me consider generating a separate SSH key that I will keep on my laptop, just for Debian.org hosts. I need to log in to some of them far too often.

On that latter post about buildd maintenance, I received a response from Riku about how he feels using tr on the client-side is wrong, and how I should instead have patched buildd-mail instead to decode MIME encodings.

Technically, he's right. Practically, he's not. When I wrote this script, it was far easier to fix the problem once, on my side of the equation, rather than every time I install or upgrade buildd. At the time, the code was in a repository that only Ryan had commit access to, and as a result most people kept patches locally. I should still have a patch lying around somewhere that has the same effect as the one that got committed, but gave up trying to use it, as in my ever-changing set of buildd hosts, one would creep up again and again that did not have the patch applied, because it was recently reinstalled after a dead disk, or because buildd was upgraded, or some such, meaning that signatures would fail and I would have a shitload of unnecessary manual work. In such a context, writing code on my client side—in casu 21 characters—is far easier than trying to fix the code centrally.

Fri, 19 Dec 2008

Metablogging

Ciarán O'Riodan blogs about how to blog, and his post is a good read. Most of it is solid advice, and I find there's little I disagree with; if you want to get a blog that's well-read by many people, then his advice is probably sound. So why am I posting this in my 'retorts' category?

Because I feel that blogging isn't something that should be taken too seriously. A blog is an outlet, a place to get your thoughts out; it is a bit of a combination between a column and the readers' letters section in a newspaper.

The writing style of a blog should reflect that; when I write a blog post, I don't care about what the truth is, I only care about my opinion. If I want to write the truth, I'll write a wikipedia article. If I want to read about the truth, I'll go and kill myself—because I'm not naive enough to think something like "the truth" exists in this life. And if I want to read a magazine-style article, how about I'll go buy a magazine instead of reading a blog post?

A blog post doesn't require references (beyond, perhaps, what you're replying to); a blog is a reference, one to the personal opinion of the author. If you think something is great, then as far as your blog is concerned, that something may be the best thing since sliced bread. If you think something is ugly, crap, and should be forgotten about, then on your blog it is. In more than one sense, blogs are like opinions: everybody has one.

That doesn't mean I disagree with most of what Ciarán wrote; on the contrary. Points 1 through 3, and 6 through 10, will help you develop a good writing style. I couldn't agree more on point 11, that you have to push for publication yourself; and it's certainly true that being aggregated is a good way to put your thoughts in context, and to expose yourself to a larger readership. But I vehemently disagree with his point 4:

It can take time. A good article-style blog entry can take six hours to write!

Not that I think writing a blog post should take no time at all—this particular one has been almost an hour in the making, now—but because I feel that, simply, articles, with all their references, scientific or other background, and whatnot, simply do not belong on a blog. A bunch of articles with an RSS feed is not a blog, plain and simple. So while I do agree that it can take time, I do think you're doing fundamentally wrong if your blog post takes more than, say, an hour and a half, to be written.

So, in the interest of being constructive, here are my own suggestions:

Don't think too much, just write. It may sound stupid, but the most important part about blogging is actually doing it, and not wondering about how or why.
Do reread if possible. While blog posts are usually read in a few minutes, they take much longer to write; it's easy to lose track of your line of thinking during that process, in which case you may end up with a completely incoherent post. That certainly is to be avoided.
Ciarán's argument that if it's worth doing, it's worth blogging about certainly holds merit, but I'd go one step further: if it's worth thinking about, it's also worth blogging about. After all, a blog is mostly a braindump, so why not?
That's not to say every thought can be turned into a coherent blog post, and I have a bunch of half-finished unpublished blog posts on my local hard disk which I may revisit at some undefined point in the future; but the principle is there.
And last, but not least: don't care about what other people are doing. Your blog is your own, not someone else's; if you get an email that your content sucks, ignore it. If you get an email that you should be writing about something else instead, ignore it. You're not getting paid for your blog, are you?

View comments on this entry (3 comments)...

Fri, 12 Sep 2008

Philip,

Sometimes you're just flat out wrong.

While I can understand your position of 'all fear-mongerers and religious fanatics should just commit suicide', I do not agree with it. However, this time, the girl you refer to didn't actually commit suicide because she fell in any of those categories.

Had you actually read that BBC story you link to in some detail, you'd have found that:

The girl was sixteen years old. While old enough to understand danger, it usually isn't old enough to understand the intricacies of science.
She took her own life after watching a sensationalist TV channel that was spreading the lie that the LHC would cause the earth to crack up

Now I agree that ignorance to science is something that should be advocated against; but if the facts of science are misrepresented through a TV channel that is only interested in its own profits, are those who do believe their only source of information then to be blamed? If the only data you get are outright lies, is the world then indeed a better place because it got rid of one "mis"believer?

I think not.

View comments on this entry (2 comments)...

Sun, 27 Jan 2008

Software RAID

Russel blogs about write intent bitmaps, which are an option in the Linux Software RAID subsystem, which works somewhat like a journal on the RAID level: every time you write to the array, you first mark the bits you're going to write to as dirty, then write them, and then mark them as clean again. This allows the RAID subsystem to have to check much less in case of a system crash, where normally the system would have to run a full array rebuild.

He'd suggested this before on the debian-boot mailinglist, and when I read that post, it seemed to make sense. However, after reading his blog post, I'm not so sure anymore. In his words:

The down-side to this feature is that it will slightly reduce performance. But when comparing the possibility of a few percent performance loss all the time and the possibility of a massive performance loss for an hour or two after a crash it seems that losing a few percent all the time is almost always the desired option.

I vehemently disagree there. Performance is irrelevant in case you have a large server park; in that case, adding another server to the park is relatively cheap—you don't run hundreds of servers on a small budget, and besides in these days of virtualization, often migrating a service from one physical server to another isn't very hard.

However, this isn't true when you're talking about small businesses, or (especially) home servers. When I have a choice between high loss of performance in case of something which happens only rarely (in my experience, the Software RAID subsystem is pretty good in recovering from a power loss without having to go through the RAID rebuild, leaving only kernel crashes and similar) or a small but continuous performance loss on my home server, there is no doubt in my mind that I will choose the former. First, my home server is a Thecus N2100, which, while powerful enough to run a number of services for my home network, is not a very fast system with somewhat low resources in comparison to some other systems; and even a small loss of performance is probably noticeable. Second, the speed of recovery which the RAID subsystem uses (and, hence, its performance impact) is manageable through the files /proc/sys/dev/raid/speed_limit_max and /proc/sys/dev/raid/speed_limit_min. Obviously lowering the speed of the RAID rebuild will make the process take longer; but if performance matters that much to you, then lowering the rebuild speed can be an option. Finally, sometimes the RAID subsystem chooses to go through a lengthy check of the entire array; it would be interesting to know whether using the write intent bitmap feature disables this too. I suspect this is not the case, and if so it would seem as if enabling this feature would cost some performance for little benefit: in normal situations these checks happen far more often than actual RAID rebuilds; so the most important source of performance loss would not be handled at the cost of extra performance loss.

In closing, I guess the right answer to this question is that it's a trade-off; that choosing the right defaults should be done by upstream (to avoid confusion), and that the user should be given the possibility (somehow) of enabling or disabling this option in defiance of the defaults at install time (perhaps only in d-i's expert mode)

Tue, 22 Jan 2008

Adrian,

No, that is not the correct key combination. You were looking for start+r.

View comments on this entry (2 comments)...

Thu, 23 Aug 2007

Chroots? Jails!

Russel Coker blogs about securing a daemon using a chroot, and offsets it against SE Linux. He argues that SE Linux provides better security; no doubt.

One downside about SE Linux, however, is that it's far more difficult to configure correctly than a chroot. Setting up a chroot involves creating a directory, copying or bind mounting stuff in there, and then just using the chroot system call (either from a shell script or from a daemon). Setting up a non-standard daemon using SE Linux involves a very fine-grained process of allowing access to files and system calls that many people inexperienced with SE Linux will find too hard to do.

OTOH, he's right that it's possible to break out of a chroot, and thus a chroot system isn't totally safe.

This is why the FreeBSD developers implemented the jail system call since FreeBSD 4: basically a chroot on steroids, it implements a basic form of virtualization -- your "chroot" gets an IP address assigned, and jailed processes cannot communicate with processes outside the jail other than through TCP/IP or some other form of networking. Processes outside the jail can modify stuff inside it, of course (it remains a simple directory).

Of course, Linux doesn't have anything like the jail system call, but it's easy to set up a similar level of security using virtualization, in a way that is far easier for the uninitiated than when using SE Linux. That's not to say that jails or virtualization will give you the same level of security that SE Linux can offer (e.g., with jails or virtualization a user can still exploit a bug in a network-facing daemon to turn your machine into a zombie; SE Linux can make this impossible), but it's a different option.

Fri, 13 Jul 2007

Traffic Shaping

Erich Schubert blogs about traffic shaping, and shows how you can do some basic traffic shaping using a rather long example. I'm sure that example works, but mine is slightly less complex:


tc qdisc add dev eth1 root tbf rate 212kbit burst 1540 latency 50ms

This is actually a literal example in the Linux Advanced Router and Traffic Control-HOWTO, and it works for me. Linux has a reasonably good default prioritizing and queueing already, and using the tbf filter doesn't replace them, whereas the detailed sfq example that Erich gave does. I'm doing this on my router (on the outgoing interface), not my laptop, which is also a rather important bit.

Of course, it working for me doesn't necessarily mean that it'll work for you too. But you might just want to try it...

Wed, 27 Sep 2006

GDM

Joey,

Debian's GDM does ship with the default file that contains lots and lots of comments. However, if you use the builtin configuration tool at least once, it will overwrite your configuration file with another file that contains just the configuration, not the comments anymore.

Perhaps that's what happened to you?

View comments on this entry (3 comments)...

Tue, 16 May 2006

On huge ISPs and multi-level support requests.

Adam

They just told you how to get past their front lines: Call their business support on the toll-free phone number she gave you. Here's my take at what happened:

You entered a question on a web form which is intended for user support questions.
A first-line technical support person called Irene (who, most likely, is not trained as a computer person; since 90% of all calls can be fixed by going with the customer through their connection and email settings, you can train anyone to be a first-line technical support person in one day, with most of the time spent in How do I handle the phone and How do I handle the ticket tracking system) had a look at your request, saw that you had problems with sending email from remote systems, and copied a standard text about mail bounces in her reply to you. Remember that there are many people out there who think they know a lot about computers because they know how to start regedit and know a few buzzwords; the presence os such words in a support request is not necessarily a sign that there's some clue at the other end of the line.
You replied that no, this does not apply, and that yes, it's really a problem at your end, because lots of words Irene does not understand. She then decided you're totally out of her league, and redirected you to their second-line support; second-line supportlines do consist of people knowledgeable about computers, because at that point it's no longer a trivial problem. Since you happen to be an ISP, which is a company in her book, she referred you to the Business support line; such a Business support line usually consists of people even more knowledgeable about computers in general and the Internet specifically, because companies usually have rather specific needs that go a bit further than I have an ADSL modem and a Windows box.

Really. Call them. You'll find that you will be talking to someone knowledgeable about what SMTP is, and who is able to put a request with SMTP administrators to fix this issue if that is required.

Take it from someone who used to work at one of Belgium's largest ISP's (at least, it was that when I used to work there—they've lost some market share since).