Entries Tagged 'Tech' ↓

A long time ago, I wrote that I had found out about Bloglines and that I thought it was a very good RSS reader. I wish to retract that statement.

Since then, I’ve been using Bloglines as my only reader, and I like it: it has a reasonably good interface, it is fast, and it keeps track of blogs all the time, so you don’t miss posts from feeds with frequent updates. All of that is good. However, a few weeks ago it decided to stop updating one of my own feeds (yes, I subscribe to my own blogs). I contacted their support team, and they told me the feed was not valid and pointed me to an online validator. I went there, fixed the error it pointed out (an invalid character), made sure it validated and waited for Bloglines to pick it up. And waited. And waited.

It hasn’t picked up on it yet. It’s been two months since it last showed new items. Even though their robot is still checking for updates to the RSS feed every few hours, and downloading it when it’s modified. That despite I having contacted Bloglines again; they never gave a definite answer.

Meanwhile, I noticed other people on the blogosphere complaining that Bloglines would every now and then “skip” articles. So, today I downloaded RSS Reader, imported my list of feeds, waited for it to update all of them and, what do you know? Bloglines is dropping articles left and right! I didn’t do a thorough check, but on a quick sample I noticed several missing articles.

Needless to say, I’m not coming back. I will certainly miss the ability of checking my feeds from different computers, but I can live with that (I haven’t found any other usable online reader, but I’m accepting suggestions). And I would no longer recommend using Bloglines, as you will probably not be seeing all articles in the feeds you subscribe to.

[Update 24.05.2005: A Bloglines employee left a comment on this entry and I sent him more information regarding the problem.]

[Update II 26.05.2005: Mark, it seems e-mails are not getting through to you, even though they are handed over to your servers; if you see this entry, please look at the comment I added.]

Google is launching a new product called Web Accelerator. It tries to speed up the online experience of users by doing local caching, using proxies (hosted by Google), pre-fetching certain pages so that they are available more quickly and fetching only parts of a page if it changed only slightly since the last time you saw it.

I still don’t know exactly what to think of it. There are obvious privacy concerns for its users: you might have a single company knowing what you search, what you surf, who are your friends (Orkut), what is in your mailbox (Gmail) and so on. Then, again, you can simply choose not to use it.

There’s also the issue of what will be like for those on the other side of it, the web content producers (that is, anyone with a web page; me, for example). Will Google proxies act effectively as an anonymiser? Will the pre-fetch increase the load in some sites? Or will caching reduce the number of registered pageviews? Can you prevent some pages from being cached? It is not clear at this point, and their page with information for webmasters is very, very information poor.

I don’t know why, but I don’t really like this product that much. I doesn’t seem to “match” the other services Google provides; it looks like a different class of product, one that is not very much “like” them. It’s just a feeling, though.

As a disclaimer, I haven’t used the product. The description makes it look like it could make my net bandwidth usage increase (mainly by pre-fetching pages I end up not visiting), and my ADSL plan still has a limited traffic allowance. When that changes, I may give it a go.

Ajax is the fashionable expression of the month, it seems. It stands for “Asynchronous JavaScript + XML”, and it’s actually a mix of several well-known technologies that people have been using for a while: XHTML/CSS, DOM, XML/XSLT, Javascript and the XMLHttpRequest object.

So, it’s nothing new, but, thanks mostly to Google (and web applications such as Gmail, Google Suggest and Google Maps) it is now in fashion. Also, it has been only recently that browsers became standard-compliant enough that these technologies can be used with relatively consistent and reliable results across the most used versions: IE 6.0 and Firefox 1.0.x.

And I’ve decided to play with it for a while, mostly to get a feel of how it works and what can be done with it (and how easily). The first step, of course, was to find something I needed done that could benefit from Ajax. The one thing I came up with was a page I have where a small part of the content is generated by a CGI script: it shows the current time and temperature in a group of cities around the world, and the temperature data can take a while to be retrieved and displayed. The effect would be that the page would partially load, stop for several seconds while the data was retrieved from the CGI, and then finish loading.

The temperature info is not the most important info in the page, and it’s ok if it’s not displayed at all; but it’s nice to have. The original code looked like this:

getweather.pl returns the city full name and the temperature as a document.write Javascript command (the “js” parameter requests a Javascript output). I replaced this with a placeholder to be filled later:

This was done for each of the cities listed on the page, of course (with a different id for each; the id will be used to reference each entry later on and insert the temperature data). Then I modified the CGI script so that it became capable of returning data in a new format, XML. The return format looks like this:

Note that it contains data for more than one city. With the data in this format, I can use Javascript methods to retrieve all the information I expect from the XML document and insert it in the right place in the HTML file being displayed.

Finally, I added to the end of the page the Javascript code that retrieves the data from the server and sprinkles it over the page that was already displayed to the user:

doRequest is the function that starts the asynchronous request (note that it needs to deal with differences between Firefox and IE). When the request finishes, finishRequest is called and, if everything went ok (return code 200), it parses the XML data and populates the DIVs created earlier on with the right data (it rewrites the innerHTML attribute of the DIVs). (technically, finishRequest is called for every change of the state in the request: state 4 means the request is finished; we ignore the other states and act only when it finishes)

So, not that complicated, and very powerful. This is a simple example that retrieves always the same information with no user interaction, but it can be easily extended to do much more interesting things (as Google has demonstrated). It “pushes the envelope” of what users may expect from online apps, really.

Windows plays soccer; Linux plays rugby. In soccer (sorry, to me this is football), whenever one player makes the slightest contact with another, he collapses to ground, writhing in agony and clutching at his ankle. Everyone gathers around and looks very worried until the referee holds up a yellow card and then—amazing!—the player springs up again, completely cured. So too Windows: as soon as anything goes wrong with any program, the whole thing collapses in a screaming heap, and requires a reboot. Linux, on the other hand, shrugs off application failures like a rugby player ignores broken fingers. Programs crash, but Linux keeps going.

From Max Barry’s blog. This says everything, I think.

SecureCon, a free two-day conference on computer security issues is happening here (it started yesterday), and I’ve attended a few of the sessions. The attendants are mostly university people, but there are a few corporate employees and non-affiliated people around. It is not a “marketing” conference; that is, presentations go into technical details and corporate presenters get some “hostile” questions at the end of their talks.

Today started with a presentation by Sam Trad, from Cisco, about their Network Access Control products, notably Cisco Trust Agent and related technologies. This is a piece of software that is installed onto network clients and that authenticates the client to the network before it’s granted access. During this authentication process, the agent tells the network what kind of software the client has installed, and the network can have policies in place that, for example, allow access only to WinXP boxes with SP2 plus the most recent patches, or Win2000+SP4+a current antivirus, and so on. The agent reportedly already comes with some antivirus packages, and will be part of future Windows OSs. For other OSs, you’re out of luck for now. A very good question raised by someone was: since we’re authenticating a host based on what the host tells us he’s got, what’s to keep this information from being spoofed? One might be able to write an exploit that takes advantage of an unpatched system and that reports it as a fully patched one to allow it to connect. The presenter mentioned something about “multiple levels of security”, but I don’t think anyone was really satisfied that this is not a problem.

This was followed by a talk by Damien Miller, from Netstar, about network worms. Nicely presented, if a bit scary at some points. His opinion, not stated that flatly, is “we’re doomed”. And I tend to agree, to some degree.

After this talk, I left the conference to do some work, and will be back for the last session, on urban hacking and hacktivism. And yesterday there was a practical session on security auditing, followed by a “hackathon” where attendants were invited to try to hack into three servers and retrieve specific pieces of information from them. Now, that was a scary session. The PCs were running Linux off a CD (the Auditor security collection from remote-exploit.org), and the available tools made it a breeze to remotely access vulnerable systems. As an example, a remote shell was started on a Win2k box with just a few keystrokes, using ready-made exploits. That’s way too easy. (during the contest, I got the two pieces of data from the Windows server, but did not have time to get into the Linux ones; a colleague of mine who attended a later session won).

Yesterday I forgot to mention exactly the type of spam that irritated me enough to post about it: referrer spam. One look at today’s stats reminded me of it, though. In short, the list of referrers is now entirely useless as a means to find out where users came from. It might as well not exist. In yesterday’s access log, which refers to Feb. 1st, virtually all of the top referrers are spammers, coming from domains like freakycheats.com (51 entries) and psxtreme.com (52), both with a large list of subdomains. And, of course, both come from all over the world, so it’s not possible to prevent it by blocking IP addresses (they are certainly using bot nets).

And they generate traffic! Some 5% of the total traffic of my web site is now caused by blog spammers (including comment, trackback and referrer), and I believe this will grow. I don’t think many people are already seeing traffic as a problem caused by blog spam, but mark my words: it will be a problem. It may be a larger traffic generator than podcasts in the not-too-distant future. And this will not be pretty.

On the one hand, I love MT-Blacklist. Yesterday alone, it blocked 136 trackback spams and 39 comment spams to my blog. Most of them were for some type of, and I’m almost afraid to use this expression, online casino. Others were for various types of quasi-legal pharmaceutical drugs (the drugs are legal; the sellers, not so much). I used to have MT-scode generating a CAPTCHA challenge for comment posters, but it stopped working thanks to something my hosting provider did, so I had to switch (and it doesn’t protect trackbacks, anyway).

On the other hand, though, I hate these guys. It’s annoying. It’s like talking against a background of white noise that gets louder and louder. It’s worse than e-mail spam, in a way, because, if it stays online (and you bet that it does, in many abandoned or not actively watched blogs) the spam “hits” many people with just one placement. For e-mail spam, it either hits the owner of the mailbox, or it doesn’t hit anyone; blog spam is closer to newsgroup spam, I think, except that almost no one reads newsgroups anymore.

My mailboxes have been reasonably clean of spam for a while now, thanks to some very good implementations of bayesian filtering. I understand that there are bayes-based comment spam filters around, but last time I checked they weren’t very usable. Maybe it’s time to either check again or to start working in one…

Many years ago, I remember that everyone used to complain that, in order to change the IP address of a Windows NT server, you had to reboot the server. It is, I agree, stupid, as this is the kind of thing you can acomplish in a Linux server with a couple of ifconfigs and the occasional restart of the odd daemon that does not handle the change well. But this has been fixed, and it’s now very quick and easy to change the IP address of any computer running any Microsoft OS relased after 2000.

So, when I had to change the IP address of a Mac server in late 2004 (earlier this week, to be more precise), I did not expect it to be very hard. After all, Macs are easy to use, right? Well, almost. It turns out that, if you run OS X 10.2.x and the “Permanent IP address” option was selected during the server setup, you’re out of luck: when it says “permanent”, it means it. The only “official” way of changing the IP address is by reinstalling the server (note that I am talking about a Mac OS X server, not a regular desktop machine). Yes, reinstalling, not rebooting.

As Donald Trump would say, very disappointing. Very, very disappointing. And I couldn’t simply fire the server, unfortunately. So I decided to ignore what Apple said and try anyway. It almost worked: the server kept trying to talk to itself on its old address, and a few minutes after rebooting it deteriorated so much that you couldn’t start new applications any more. And “ls -l” didn’t work at all (“ls” without the “-l” did work).

Since there was nothing visible in the server configuration pointing to the old address, I did a large “grep” and found a binary file under /private/var/db with a mention to it. I bravely used vi to edit the file, changed the address, rebooted… and it worked!

After all of this, we found out that Apple makes available a script to change the IP address of a Mac server. It’s a shell script that asks you for all the information (including the old IP address and netmask, which it should be able to get from the server configuration) and does everything. It seems to work very well, so, if you need to do it, I recommend this process instead of the massive grep. But the manual way is more satisfying.

Forget The Apprentice or The Rebel Billionaire. The reality show of choice for software developers is The Code Room:

In an inner-city warehouse sits a laptop and a few partially charged batteries. Three developers are taken to The Code Room [...] and asked to design and develop an e-commerce Web site.

Yes, it’s produced by Microsoft, and it’s completely .Net-centric, but it’s fun to watch, and it’s a nice twist on those “business” reality show that are starting to become ubiquitous.

This is a true story. It happened yesterday, to yours truly.

11:00am. Coffee time, the worst possible time to ask for support. A girl comes into Technical Services saying that she changed her password and forgot what she changed it to. Since the help desk is closed, we’re the only ones who can help… When?, ask I. “Just now”. Well, that’s not much of a memory… but, well, I’ve seen weirder things. “Do you remember your previous password?” Yes, she says. Ok, I revert it to the previous one, tell her to wait 15 minutes for it to propagate, and send her on her way.

Not half an hour later, she’s back. The previous password does not work either, she claims. Odd. I check it, it should work. So I set her password to something else, write it on a piece of paper, tell her “this is your new password, all lowercase; change it today or it will expire”, and off she goes.

Mid afternoon, and who comes in? She says that she logged in with the password I gave her, then she changed it and now she can’t log in anymore. I suspect her keyboard might have a problem, so I ask her to try on mine; it fails. So I change it back to the password I gave her earlier, and ask her to change it again.

A few minutes later, she comes back saying that the password I gave her does not work either. Well, now I know she has to be doing something wrong. So I log in to her account with that password, and it works. I ask her to do it on my keyboard, just to check. And I watch in horror as she pointedly presses the shift key while typing a password containing only digits and lowercase letters! Well, that explains it. I tell her about upper- and lower-case letters, the shift key and things not to do; a colleague helps a little with that. And she seems to understand. And off she goes.

And back she comes. Not working, she says. Ok… I need to see this. So I go with her to the lab, five floors down, to watch as she logs in. And there I see, in all its glory, a bright green Caps Lock light on her keyboard. I touch the Caps Lock key and tell her “try now”. She does it and, surprise of surprises, it works. So I have her change the password again, and watch as she does. And then I tell her to check for that light and, if in doubt, to type the password in the username field to see if it looks like what she expects.

And she’s a Postgrad student in Computer Science. What’s the world coming to?

This is how the story ends: our reseller sent us a new release of the software for the firewall (not an official release, though); we installed it, and everything suddendly worked. So, it was actually a bug, and (surprisingly) we got a fix from Cisco in just a few days. And now everyone is happy, and a firewall is going to be installed as planned.

Just for the record, putting a DHCP server behind the firewall did work, as, or course, we did not have DHCP packets crossing the firewall anymore. That is, until we added a second VLAN behind the firewall. With more than one VLAN, we need either (a) to have a DHCP server on each VLAN, or (b) to have interfaces on each VLAN on the same DHCP server, or (c) to relay requests across the firewall. (a) or (b) are fine as long as you don’t have many VLANs, but we do. (c) is perfect, but then we go back to the same issue, which is dhcprelay not working.

The last update from our reseller (and support provider) is that the recommended version is no longer x.x(x.1) but x.x(x.16), and that they’re still waiting for Cisco to release it. I’ll let you know how it goes…

So, take a firewall module for a large switch made by a five-letter manufacturer that shall not be named (on the other hand, why not? naming it will help people Googling for it. It’s Cisco). Start to plan and test a migration path for all the equipment you already have, so that you end up with everything behind the firewall. Obviously, you don’t want to move everything on the same day.

Next, add to the mix a DHCP server that provides IP addresses to most things on the net, according to a set of rules (each MAC address is allocated the same IP address every time). This server, like everything else, is on the “outside” of the firewall.

Then, just to make sure that you did things right and that you can get traffic to flow across the firewall, you move one PC to the “inside” and try to make it talk to the net. It won’t, because it can’t get an IP address from the DHCP server. You enable “dhcprelay” just as the manual tells you to, correcting for some syntax errors in the examples in the manual, and it still won’t work. So you give the PC a fixed address and try again. Still no go.

After some tweaking with routes and OSPF configuration, voilà, it works! Pings go through, DNS works, even web browsing. So, ok, let’s try DHCP again. But, still nothing. Read manuals, tweak things, read some more. Still nothing. Look at the server, it sees the requests. Turn debug on in the firewall, it claims to be forwarding the replies to the PC. But the PC never sees them.

Ok, let’s bring the big guns out. Mirror a switch port, start ethereal, and look at the network traffic. Ok, there goes a DHCPDISCOVER, but where is the DHCPOFFER? Hmm, and what is this ARP request doing here? The firewall is sending an ARP request to the “inside” network asking who has A.B.C.D, where A.B.C.D is the address of the default gateway for the firewall. Can you see what is wrong with this? Two things: one, the default gateway is in the “outside” network; two, why does it need to ARP the gateway to forward a DHCPOFFER packet? It’s not even addressed to an IP address!

So, quick experiment: take the default route out, and try again. And it works!

Where are we, then? DHCP relaying works, as long as there is no default route set. If a default route is set, the firewall seems to try to do the right thing, but it does it in the wrong way. Seriously wrong.

Time to get support, then. We contact our provider, tell them about the issue and, after a few e-mails back and forth, they seem to understand the problem. The next day they report back saying that there is a confirmed bug that seems to match our situation. The description of the bug is “DHCP relay does not work in customer setting, not reproducible in the lab”. No mention of interaction with default routes. And the software versions in which the bug is confirmed do not match ours. But they do recommend an upgrade to a version that is 0.0.0.1 higher than ours. Ok, we’ll give it a shot. Go to cisco.com, locate the software for the firewall module and, surprise surprise, the latest version available is the one we’re running; the one they recommended is not available.

Another contact with support later, we find out that the version is indeed not available, and they don’t know when it will be. Well, isn’t that great?

In short: dhcprelay does not seem to work in Cisco firewall modules when a default route is set. A bug fix may or may not exist, but we will only know for sure when Cisco decides to release the new version of the software.

If anyone knows of anything related to this issue, please let me know. Meanwhile, I’ll be setting up a new DHCP server inside the firewall.

I wonder if I’m the only person who was disappointed by the new Google Desktop Search that was unveiled yesterday…

The basic idea is great: a desktop mini-application that will allow you to search your own local data with the same completeness we all came to expect from Google. The initial description of the tool is great, as well: search documents, IM chats, e-mails, and even web pages you have visited, even if they’ve changed since then.

The implementation, though, still leaves something to be desired: it will only search pages visited with Internet Explorer (come on, even CERT is telling people not to use IE), e-mails received with Outlook, IM chats on AIM, and MS Office documents (granted, it will search images and plain-text documents as well). And, obviously, it only works on Windows.

Ok, that will be enough for the vast majority of computer users out there. But not for most geeks. I expected more from Google… (well, it’s still beta, and they say they’re “considering” supporting Firefox more thoroughly, so there’s still hope).

Do not rsync a file system onto the wrong directory. Especially not if the directory in question already had some content.

At least it was early in the day. And easy to recover from, with another (correct) rsync. Which is still running.