558 words
Yesterday, Jan-Philipp and me visited Zoran for some Powerbook related geeky goodness. We are probably the 'Mac people' in our department.
First we solved a completely unnecessary problem caused by stupid CD burning software – that for some reason renamed all files to end in '.mp3' and made apparent by iTunes' stupidity – as it refuses to recognise files which are clearly AAC encoded just because their name ends in '.mp3'. Even I can see at a glance what file format we're dealing with when looking at the file's contents – so surely a piece of software should be able to achieve the same thing.
And then we wanted to do some networking playing/fun. That turned out to be interesting at first because we didn't have a switch around. However, we did have one network cable with the internet connection, two Powerbooks with Airport and one iBook without Airport. These being Macs and me being a friend of that 'just works' thing, the solution was obvious: Plug one Powerbook into the network, set it up to do internet connection sharing via Airport and Firewire and connect the other two computers that way.
Using the internet worked right away without a problem. However, this slightly unusual setup made us see a few problems that you don't usually run into. Probably the most obvious one is that the two computers getting their connection off the Powerbook won't be able to communicate with each other as they live on distinct subnets (or some fancy words like that – I'm not a networking expert, so I'll use terminology randomly).
This means that if you want to play a game with three people, say, you'll at least need to set this up carefully, with things being hosted by the computer that everyone can communicate with. And even with such careful setup it didn't work – my impression being that this multi-network stuff isn't entirely transparent to the software. Different programs dealt with the situation with various levels of success. And even the same software didn't seem to act entirely reproducibly in this situation.
Rendezvous is the next big thing for local networking – and exactly situations like the one we were in. It does deal with one computer being connected to multiple networks. A few observations: Firstly, it also suffers from the fact that it only works on a single subnet. It does automatically set up the infrastructure for all the subnets you're connected to, though.
Secondly, while the infrastructure is there, it seems like don't always deal with this gracefully. iChat would get it right at times and not get it right at others – as would iTunes or file sharing. Looking at the Rendezvous services provided on the networks with Rendezvous Browser, I observed that there were three instances of my own machine in there – probably one for every network – but each of them lists the same IP address, which seems a bit odd.
In a final step, we managed to overcome the problem that two of the computers couldn't talk to each other on the network: As those two were connected via FireWire and Airport respectively, they both had an unused Ethernet port... which we used to create a circular network. While a couple of things still worked in that particularly twisted setup, it seemed to confuse programs even more.
November 23, 2003, 21:50
I imagine your apps would be completely confused when you connected all three machines via both Firewire and Ethernet — at that point, you had three networks, each computer was on two of those networks, and none was on all three — it almost sounds like a standardized test question: “Given three Macs, attach them together so that each is…” :)
It is actually possible to get something that convoluted working, but not without constructing static routes (see the manpage for the “route” command.) The OSX networking stack is capable of doing this, but the sort of convolutions required would quickly put you in the realm of the sorts of people who make far more money per hour than I do.
November 24, 2003, 1:57
I was definitely going for the ‘just works’ thing here.
Heck, those computers were next to each other, they should be smart enough to handle those things.
November 25, 2003, 22:33
I’m certain there’s enough smarts there for things to ‘just work’, but network routing is one of those fields that adheres very closely to a ‘first do no harm’ philosophy. Network administrators are very, very, conservative people by nature, and get extremely nervous when machines start deciding how to route between different networks on their own — it only takes one badly configured router to bring a LAN to its knees or open a wide-open backdoor to an organizational network. If Rendezvous worked on anything besides individual subnets, network admins would ban it from their networks in a heartbeat (in much the same way that they’ve exiled Appletalk to Outer Bongolia.) The limitations built into Rendezvous were a concession to folks like the IETF.
November 26, 2003, 1:37
Hm,
I think I can see where you’re coming from. Of course there could be chaos if things were wildly routed around in larger networks - something that doesn’t apply to the situation we were in.
Basically the problem seems to be that while we want computers to communicate, on the other hand we don’t want them to do so freely. There’s always some control-freak administrator around to keep us from doing so. All this control-freakery along with insecure systems, the criminals waiting to abuse them and paranoia perhaps are a curse in my opinion.
Everybody who has ever been kept behind a firewall or NATed away while being only slightly ambitious about his network use knows that these techniques just suck.
I am taking a mixed point of view on this. While I can see why people are keeping networks from doing their job excessively well, I often have the impression that BOFH’s are control freaks who like bossing people around and thus love locking down any port that they don’t use personally (What’s the security case for me being able to use AIM in our department but can’t access external POP or AFP servers? The admin only using IM and FTP and his own mail server, is the best explanation I’ve come up with.)
The same goes for AppleTalk, imo. It would be a little extra effort for the admins to at least route it throughout the university. Extra work without benefits for themselves so it’s not done… Luckily I seem to be on the same physical subnet as our printer, so I can use AppleTalk for printer discovery and printing - meaning I can still print when the print queue has crashed once more.
November 26, 2003, 22:02
Perhaps I can put it like this: Most ways of securing a network are not precisely doing that. Instead they block a vast superset of actions. While this may prevent bad things from happening it also prevents many other things that people may want to legitimately do.
So I think that security people aren’t exactly brilliant at their job. If they were, their means of securing networks wouldn’t interfere with people’s work - even if they do something unpredicted.
Perhaps weapon control is an interesting analogy. The aim would be to minimise harm done to people. Thus banning guns, explosives and nukes from the public seems like a good idea, as they have very few legitimate uses. Still, this system isn’t perfect as it is causes quite a bit of hassle for people who are park rangers, say, and need a gun for their job. Ideally (and equally impossibly, I guess) you’d have free access to weapons for everyone - but you’d have weapons that only work in a legitimate way. On the other hand, the situation we have in many networks is one where knives and toothpicks are also banned (i.e. ubiquitious post WTC-attack airports), which is very inconvenient.
[To get sidetracked even further, this probably implies that a point could be made for ‘Palladium’ style authentification system, as they could ensure the ‘legitimate use only’ thing in theory - as long as you exclusively want to communicate with devices sporting that technology, that is…]
November 26, 2003, 22:17
Coming to the defense of my fellow network people, they have a very delicate balance to maintain. They have two really significant problems to deal with: there really are bad people out there who want to do harm to their networks and the machines on them — they have the firewall logs and the late nights dealing with stupid things like Blaster and Nimda to prove it, and they have users who are quite less sophisticated than they sometimes like to think who can cause a great deal of havoc with misconfigured computers. Every day I deal with Windows users who have downloaded one or another ‘helpful’ utility (calendars, weather indicators, toolbars) which have backdoors built into them. The unfortunate control-freakery is the only workable approach at the moment, I’m afraid — admins try to make an impossible job bearable by limiting the number of variations they have to deal with. When the admin gets a call from the CEO at 3AM because the whole corporate network has been brought down because Fred in Accounting brought a trojan horse from home, the CEO wants to know why the network people didn’t prevent it from happening. What happens if some user decides to, say, turn on DHCP serving on his workstation, or inadvertently gets a trojan FTP server or spam relay backdoor involved? All these things have happened at various companies where I’ve worked. There just aren’t enough hours in the day to predictably prevent these things.
A large problem is that a great many of the protocols we use on networks today were designed for a more innocent time. SMTP is a great example — it worked well for years, but spammers took advantage of the very openness that made it so useful. Back in the early 90’s, I could send emails from anywhere because no one had to lock down their mail servers. It’s really difficult to design security into something that didn’t have it built in from the start (that’s the big problem with Windows).
Appletalk’s a different issue. It’s an obsolete, chatty protocol designed for low-speed links, and it causes problems on large networks because of the overhead of devices announcing “I’m here!!!” every 10 seconds. The reason Apple designed Rendezvous is so that they could have the lone advantage of Appletalk (discoverability) work smoothly on TCP/IP networks.
November 27, 2003, 1:50
Just because I can understand why people run networks the way I do doesn’t mean I have to like it, right? In particular the standard arguments seem to be frequently abused for admin lazyness. The way it should work is that when I want to do something, I should be able to do it. My admin should make sure that I can do it without hurting myself or the network.
The way things frequently happen is that you have to approach your local BOFH submissively and be dismissed first, because everyone’s considered stupid. Then you, the user, have to prove that you’re worth the BOFH’s time needed to get the thing working. In addition you may even have to listen to their explanations - which you don’t give a damn for - and watch them do the work, because they won’t do it once you’re not pushing them.
As a moderately advanced user and a Mac user, I’ve seen this too often. Sometimes I even thought “gosh, that’s a bad and complicated way to solve that particular problem” but didn’t bother to argue with the admin as that usually is a waste of time and it’s not my network that’s being screwed.
Mostly there is a complete disparity between the user and the admin. The user has no power and knowledge of the network (even though you may have good assumptions on how things work, you don’t know, right?) and is treated that way. He has to believe whatever he is told. Even if the user researches something and suggests it, he will have to convince the admin that it’s a good idea and have to fight the admin’s built-in “not invented here” mode.
The irony is that the admin should be like the caretaker of the building. Not interfere with your work and make sure you can do whatever you want to - whilst taking care of the safety considerations and finding solutions for potential problems himself. Sadly, that’s not how it works in many cases I have seen. Many BOFHs are bullyish enough to revert the relation to them being the actual bosses and people who have more important jobs (or even those employing and paying them) giving in either because they think “he’ll know” or because they know from experience that arguing with the admin is not worth their time.
That’s bad. Perhaps more money will buy better admins. But I am not too sure it will. It seems to be more of a personality thing.
In short…
Current situation: I want AFP connections working. this means I have to find out and explain what all this is about, what the relevant things to be changed are and still won’t get that done because of ‘security reasons’.
Good situation: I tell the admin “I can’t connect to Steffen’s computer”. He’ll know that I have a Mac, figure out what the problem is and solve it safely.
Quite different stories.
Re: Trusting protocols… case in point would be that LDAP/DHCP embarrassment that Apple caused itself.
Re: AppleTalk… while it may be obsolete by now, AFAIK it wasn’t all that chatty in later revisions. Also, chattiness always seemed like a bogus argument to me used to keep AppleTalk off the network. While Rendezvous may become a worthy remake of NBP, it’s still immature in comparison. I have seen many glitches in Rendezvous, be it on the networking side or in the way applications handle it. It will probably take some more time for it to be as reliable and mature as AppleTalk.
I have always thought of AppleTalk’s discovery feature as ‘magic’. This is one of the things that make computers great: you open the Chooser and your printer just appears there. And seeing the Rendezvous printer in our department appear automatically will put same smile on my face…
How will the world of TCP/IP handle network zones, by the way? Ten years ago I could comfortably browse all the university departments using AppleTalk zones. These days all I can use comfortably is whatever is on our local network. That’s quite a decrease in user-friendlyness.
November 27, 2003, 20:43
The printer thing is another issue apart from the underlying network protocol, IMO. Although it’s become fashionable to deride the Chooser (its modality, etc.), it really was a nice interface for dealing with a network full of printers. There’s no reason that you couldn’t implement the same sort of interface on top of Rendezvous — there are provisions there for breaking things down by subnet in TCP/IP the same way that Appletalk broke things down by zone, it’s just that no one ever goes to the extra level of resource tagging to do so.
I imagine things are different on a university network are different from a corporate network, in that people who claim to be computer savvy actually are. On most corporate networks, it seems every department has a guy who fancies himself an expert but who in reality knows just enough to hang himself and everyone else in range. This guy is the reason your network people always go into CYA mode when you ask for something. They remember the last time this guy asked for something vague, ill-advised, and then complained to his boss when they didn’t jump on it right away. They then have to waste time explaining why what this guy asked for was so stupid, and they have to explain this to his boss and their own boss as well, and meanwhile they’re not fixing your problem because this guy’s idiocy caused them 4 hours of extra work, because the stupid utility he installed screwed up his machine and they have to rebuild it, and he still complains because it’s not exactly the way it was before he screwed it up.
November 30, 2003, 15:48
I guess we don’t disagree too much in the end. Programmers and admins are too lazy to give us really nice networks™, while users are always capable of ruining things with the best intentions.
Actually, I am not too sure about the latter. A single user being able to break a whole computer or even a whole network sounds like a Windows phenomenon to me. I’ve never seen that happen on a Unix network. While I am not working in the network business, I have the feeling that actually breaking things or even breaking thing irreversibly is much harder to do in a standard Unix setup.
I wouldn’t claim that all university users are computer savvy. I wouldn’t claim that I personally get things right all of the time either. My idea is rather that a well-run network can just deal with problems such as users in a reasonable way. (I always have to think of our dishwasher here. While you’re not supposed to do that, you can still open or stop it in mid-cycle and then simply hit the power-button again to re-start it where it stopped without any harm done. That’s the fault tolerance I like. I can do whatever I want - even break the rules - and the system recovers gracefully.)
November 30, 2003, 18:48
