Tuesday, May 06, 2008
Being annoyed by rug?
Rug/zmd in SLES10-SP1 is still a headache maker. Novell knows this, but I strongly suspect that we'll have to wait until SLES11 before we get anything improved. OpenSUSE now has zypper which works pretty good, and I think you can do it in SLES if you want, but I haven't tried.
One of the chief annoyances of rug is that the zmd.db file kept in /var/lib/zmd/zmd.db gets corrupted far too easily. And when that happens, rug can take HOURS to return anything. If it returns anything at all.
The fix for it is easy, stop zmd, delete the zmd.db file, restart zmd. Since I'm doing this fairly often, I've whipped up a bash script to do it for me.
nukezmd
One of the chief annoyances of rug is that the zmd.db file kept in /var/lib/zmd/zmd.db gets corrupted far too easily. And when that happens, rug can take HOURS to return anything. If it returns anything at all.
The fix for it is easy, stop zmd, delete the zmd.db file, restart zmd. Since I'm doing this fairly often, I've whipped up a bash script to do it for me.
nukezmd
#!/bin/shSimple, to the point. Works.
#
# For killing ZMD when it is clearly hung. An all too often occurance.
#
declare PIDZMD
# First get the PID of ZMD
printf "Getting PID... "
let PIDZMD=`rczmd showpid`
printf "$PIDZMD\n"
# Then unconditionally kill it
printf "Killing zmd hard... \n"
kill -9 $PIDZMD
# Remove the old, inconsistent database
printf "Nuking old database... \n"
rm /var/lib/zmd/zmd.db
# Restart ZMD, which will build a new, consistent database
printf "Restarting ZMD\n"
rczmd start
Monday, May 05, 2008
Linux @ Home
My laptop at home dual-boots between openSUSE and WinXP. There are a few reasons why I don't boot the Linux side very often, some of them work related. And, what the heck, here are the two reasons.
1: Wireless driver problems
I have an intel 3945 WLAN card. It works just fine in linux, well supported. What throws it for a loop, however, are sleep and hibernate states. It can go one, two, four, maybe five cycles through sleep before it will require a reboot in order to find the home wireless again. If it doesn't lock the laptop up hard. Since my usage patterns are heavily dependent upon Sleep mode, this is a major, major disincentive to keep the Linux side booted.
I understand the 2.6.25 kernel is a lot better about this particular driver. Thus, I wait with eager anticipation the release of openSUSE 11.0. This driver is currently the ipw3945 driver, and will eventually turn into iwl3945 driver once it comes down the pipe. What little I've read about it suggests that the iwl driver is more stable through power states.
2: NetWare remote console
I use rconip for remote console to NetWare. Back when Novell first created the IP-based rconsole, they also released rconj along side ConsoleOne to provide it. As this was written in Java, it was mind bogglingly slow. This little .exe file was vastly faster, and I've come to use it extensively. Unless I get Wine working, this tool will have to stay on my Windows XP partition. It works great, and I haven't found a good linux-based replacement yet.
Time has moved on. Hardware has gotten faster, and the 'java penalty' has reduced markedly. RconJ is actually usable, but I still don't use it. Plus, it would require me to install ConsoleOne onto my laptop. It's 32-bit, so that's actually possible, but I really don't want to do that.
The Remote Console through the Novell Remote Monitor (that service out on :8009) has a nice remote-console utility, but it also requires Java. I'm still biased against java, and java-on-linux still seems fairly unstable to me. I don't trust it yet. It also doesn't scale well. When I'm service-packing, it is a LOT nicer looking to have 6 rconip windows up than 6 browser-based NRM java-consoles open. Plus, rconip will allow me access to the server console if DS is locked, something that NRM can't do and is invaluable in an emergency.
Once the wireless driver problems are fixed, I'll boot the linux side much more often. Remote-X over SSH actually makes some of my remote management a touch easier than it is in WinXP. And if I really really need to use Windows, my work XP VM is accessible over RDesktop. There are a few other non-work reasons why I don't boot Linux very often, but I'll not go into those here.
So, oddly, NetWare is partly responsible for keeping me in Windows at home. But only partly.
1: Wireless driver problems
I have an intel 3945 WLAN card. It works just fine in linux, well supported. What throws it for a loop, however, are sleep and hibernate states. It can go one, two, four, maybe five cycles through sleep before it will require a reboot in order to find the home wireless again. If it doesn't lock the laptop up hard. Since my usage patterns are heavily dependent upon Sleep mode, this is a major, major disincentive to keep the Linux side booted.
I understand the 2.6.25 kernel is a lot better about this particular driver. Thus, I wait with eager anticipation the release of openSUSE 11.0. This driver is currently the ipw3945 driver, and will eventually turn into iwl3945 driver once it comes down the pipe. What little I've read about it suggests that the iwl driver is more stable through power states.
2: NetWare remote console
I use rconip for remote console to NetWare. Back when Novell first created the IP-based rconsole, they also released rconj along side ConsoleOne to provide it. As this was written in Java, it was mind bogglingly slow. This little .exe file was vastly faster, and I've come to use it extensively. Unless I get Wine working, this tool will have to stay on my Windows XP partition. It works great, and I haven't found a good linux-based replacement yet.
Time has moved on. Hardware has gotten faster, and the 'java penalty' has reduced markedly. RconJ is actually usable, but I still don't use it. Plus, it would require me to install ConsoleOne onto my laptop. It's 32-bit, so that's actually possible, but I really don't want to do that.
The Remote Console through the Novell Remote Monitor (that service out on :8009) has a nice remote-console utility, but it also requires Java. I'm still biased against java, and java-on-linux still seems fairly unstable to me. I don't trust it yet. It also doesn't scale well. When I'm service-packing, it is a LOT nicer looking to have 6 rconip windows up than 6 browser-based NRM java-consoles open. Plus, rconip will allow me access to the server console if DS is locked, something that NRM can't do and is invaluable in an emergency.
Once the wireless driver problems are fixed, I'll boot the linux side much more often. Remote-X over SSH actually makes some of my remote management a touch easier than it is in WinXP. And if I really really need to use Windows, my work XP VM is accessible over RDesktop. There are a few other non-work reasons why I don't boot Linux very often, but I'll not go into those here.
So, oddly, NetWare is partly responsible for keeping me in Windows at home. But only partly.
Labels: linux, netware, novell, opinion, virtualization
Monday, April 28, 2008
The GPL in a software-as-a-service world
Just this last weekend I went to Linuxfest Northwest, which is held here in Bellingham. This is nice! It's just a short drive.
One of the talks I went to was held by Ted Haeger, currently of Bungee Labs. The topic of the talk was one he had just posted to his blog, "Sharing Source Code In The Cloud".
One point he brought up that I hadn't heard of before is that the GPL triggers when you 'convey' the software to someone else. And that the GPL specifically excludes where the software is hosted on a server and users just use the software there, so long as the software itself never leaves the company in question. This is exactly what Google did and still does. All of their search IP was built on an OSS platform, but is still held as the crown jewels of their company; all because they haven't given the software to anyone else.
Apparently, this 'loophole' is being exploited by a LOT of new companies trying to get in on the software-as-a-service market. Such as Bungee Labs, as it happens. What effect will this have on the state of GPLed software? Hard to say, the market is still in its early days.
It makes you think.
One of the talks I went to was held by Ted Haeger, currently of Bungee Labs. The topic of the talk was one he had just posted to his blog, "Sharing Source Code In The Cloud".
One point he brought up that I hadn't heard of before is that the GPL triggers when you 'convey' the software to someone else. And that the GPL specifically excludes where the software is hosted on a server and users just use the software there, so long as the software itself never leaves the company in question. This is exactly what Google did and still does. All of their search IP was built on an OSS platform, but is still held as the crown jewels of their company; all because they haven't given the software to anyone else.
Apparently, this 'loophole' is being exploited by a LOT of new companies trying to get in on the software-as-a-service market. Such as Bungee Labs, as it happens. What effect will this have on the state of GPLed software? Hard to say, the market is still in its early days.
It makes you think.
Thursday, April 17, 2008
And a gripe
2.5 hours is too freakin' long for "rug lu" to tell me which patches need application to this particular OES2 server. This needs fixing. I hope its fixed in SLES10 SP2.
Wednesday, April 09, 2008
Stupid user tricks
I had a case of this the other day. I was minding my own business, when suddenly one of my monitors starts going wonky. This is an LCD monitor, but an older one, so it isn't inconceivable that it could be going bad. How else would I explain the weird spots that were showing up on it? They looked like this:
Which looks like weird hot-spots in the screen. So I started to muttering. Plus, the screen was noticeably dimmer. Futzing with the brigthness and contrast settings didn't do a thing for it either. Plus it seemed to follow no matter which window I put on the hot spots.
Then, I realized what the problem was.
Compiz. Somehow, the rdesktop window that represents had been made slightly transparent, and the wall-paper was showing through. This screen shot is with the transparency fully down, you can barely make out the ConsoleOne icon in it.
So no, I didn't have a monitor going bad, I had a mouse mis-cue somewhere that caused that rdesktop window to go a bit transparent. No worries!
Aie.
Which looks like weird hot-spots in the screen. So I started to muttering. Plus, the screen was noticeably dimmer. Futzing with the brigthness and contrast settings didn't do a thing for it either. Plus it seemed to follow no matter which window I put on the hot spots.
Then, I realized what the problem was.
Compiz. Somehow, the rdesktop window that represents had been made slightly transparent, and the wall-paper was showing through. This screen shot is with the transparency fully down, you can barely make out the ConsoleOne icon in it.
So no, I didn't have a monitor going bad, I had a mouse mis-cue somewhere that caused that rdesktop window to go a bit transparent. No worries!
Aie.
Thursday, March 20, 2008
BrainShare Thursday
Not a good day. My first course, "Advanced BASH," could more accurately be described as, "BASH scripting tips & tricks". I then proceeded to skip the other three sessions I had signed up for.
BASH tips and tricks. I got a lot out of it, but the developers around me were quietly derisive.
ZEN Overview and Features
Not so much with the futures, but it did explain Novell's overall ZEN strategy. It isn't a coincidence that most of Novell's recent purchases have been for ZEN products.
TUT303: OES2 Clusters, from beginning to extremes
This was great. They had a full demo rig, and they showed quite a bit in it. Including using Novell Cluster Services to migrate Xen VM's around. They STRONGLY recommended using AutoYast to set up your cluster nodes to ensure they are simply identical except for the bits you explicitly want different (hostname, IP). And also something else I've heard before, you want one LUN for each NSS Pool. Really. Plus, the presenters were rather funny. A nice cap for the day.
And tonight, Meet the Experts!
- Novell Open Enterprise Server 2 Interoperability with Windows and AD. All about Domain Services for Windows and Samba. Neither of which we'll ever use. No idea why I wanted to be in this session.
- Rapid Deployment of ZENworks Configuration Management. Other people around here have suggested that if we haven't moved yet, wait until at least SP3 before moving. If then. So, demotivated. Plus I was rather tired.
- Configuring Samba on OES2. CIFS will do what we need, I don't need Samba. Don't need this one. Skipped.
BASH tips and tricks. I got a lot out of it, but the developers around me were quietly derisive.
ZEN Overview and Features
Not so much with the futures, but it did explain Novell's overall ZEN strategy. It isn't a coincidence that most of Novell's recent purchases have been for ZEN products.
TUT303: OES2 Clusters, from beginning to extremes
This was great. They had a full demo rig, and they showed quite a bit in it. Including using Novell Cluster Services to migrate Xen VM's around. They STRONGLY recommended using AutoYast to set up your cluster nodes to ensure they are simply identical except for the bits you explicitly want different (hostname, IP). And also something else I've heard before, you want one LUN for each NSS Pool. Really. Plus, the presenters were rather funny. A nice cap for the day.
And tonight, Meet the Experts!
Labels: brainshare, clustering, linux, novell, NSS, OES, storage, zenworks
BrainShare Wednesday
The Wednesday keynote was, indeed, a bunch of demos. It was also mostly pointless as far as the technology I'm concerned with. Lots of GroupWise (don't care), lots and lots of PlateSpin (can't afford it), lots of Zen (not the bits I'd use).
That said, the new GroupWise WebAccess is gorgeous. I wish Exchange had their non-ActiveX pages look that good.
TUT175: RBAC: Avoiding the horror, getting past the hype
Mostly about IDM as it turned out. Only minimally interesting from an abstract viewpoint about roles in general.
TUT 277: Advanced eDirectory Configuration, new features, and tuning for performance
I learned a few things I didn't know, such as the fact that each object as an "AncestorList" attribute listing who their parent objects are. This apparently greatly speeds up searching. SP3, coming out this Summer, will have faster LDAP binds for a couple of reasons. Right now Novell is recommending 2 million objects as a reasonable maximum size for a partition for performance reasons.
And also they reiterated something I've heard before...
TUT221: iPrint on Linux, what Novell Support wants you to know
A nice session from a mainline support guy about the ways people don't do iPrint on linux correctly. We're not going there until pcounter can run in linux, so this is still somewhat abstract. But, nice to know.
That said, the new GroupWise WebAccess is gorgeous. I wish Exchange had their non-ActiveX pages look that good.
TUT175: RBAC: Avoiding the horror, getting past the hype
Mostly about IDM as it turned out. Only minimally interesting from an abstract viewpoint about roles in general.
TUT 277: Advanced eDirectory Configuration, new features, and tuning for performance
I learned a few things I didn't know, such as the fact that each object as an "AncestorList" attribute listing who their parent objects are. This apparently greatly speeds up searching. SP3, coming out this Summer, will have faster LDAP binds for a couple of reasons. Right now Novell is recommending 2 million objects as a reasonable maximum size for a partition for performance reasons.
And also they reiterated something I've heard before...
You know how back in the NetWare 4 days, we said to design your tree by geography at the first level, and then get to departments? Um, sorry about that. It was great back then, but for LDAP or IDM it really, really slows things down.Yep. I took my first class for my CNA when 'Green River' was just coming out, or was just out. So I remember that.
TUT221: iPrint on Linux, what Novell Support wants you to know
A nice session from a mainline support guy about the ways people don't do iPrint on linux correctly. We're not going there until pcounter can run in linux, so this is still somewhat abstract. But, nice to know.
- The reason that some print jobs render differently than direct-print jobs, is because of how Windows is designed. Direct-print jobs render with the 'local print provider', and iPrint jobs render with the 'network print provider'. This is a Microsoft thing, not an iPrint thing. You can duplicate it by setting up a microsoft IPP printer (assuming you're not mandating SSL like we are) and printing to the same printer with the same driver.
- The Manager on Linux doesn't use a Broker, it uses a 'driver store'.
- The Manager on NetWare doesn't always bind to the same broker. I didn't know that.
- It is recommended to have only one Broker, or one driver store per tree.
- Novell recommends using DNS rather than IP for your printer-agents, check your manager load scripts.
Labels: brainshare, edir, linux, microsoft, netware, novell, OES, pcounter, printing
Tuesday, March 18, 2008
BrainShare Tuesday
Today started off with a bit of panic, as I hadn't set my alarm. Me being a west-coaster, 7:20 (when I woke up) is an entirely reasonable time to get up as far as my body is concerned. Only, I needed to get dressed and breakfasted before my first session at 8:30. Aie! I had to eat quick, but I got there. Didn't get a chance to check work email, though.
ATT326: Advanced Linux Troubleshooting
An ATT, therefore hard to summarize. But I learned about a few new commands I didn't know about before. Like strace. And vimdiff.
TUT130: Challenges in Storage I/O in Virtualization
Another nice one, but an emergency at work (printing down in a dorm, during finals week) distracted me heavily during the first half of it. Which resulted in the following note in my notes:
TUT216: OES2 SP1 Architectural Overview
There is a LOT of new stuff in SP1.
TUT211: Enhanced Protocol Support in OES2 SP1
This is the session where they went into detail about the AFP and CIFS support. They said that netatalk, the existing AFP stack on Linux, gets really slow once you go over the 20 concurrent users. Whoa! I can soooo understand why Novell felt the need to make a new one.
Tonight was the night formerly known as 'Sponsor Night,' but has a new name now that everyone who gets a booth is no longer a 'sponsor'. Some are sponsors, some are exhibiters. I can't keep track. Anyway, today was their party. "World of Novellcraft!" Homage to vid-gaming.
Lots of Wii, lots of Rock Band, some Halo, lots of women dressed in Renaissance Festival gear getting their pictures taken by the 90%+ male audience. I've blogged before about my ambivalence about Sponsor Night. I lasted until about 7, when I came back to the hotel.
Tomorrow I have an actual LUNCH BREAK in my schedule! Ooo! AndSoul Asylum Soul Coughing Collective Soul plays the concert! I've been listening to two of their CD's for the past two months so I think I may even know a few songs by now.
ATT326: Advanced Linux Troubleshooting
An ATT, therefore hard to summarize. But I learned about a few new commands I didn't know about before. Like strace. And vimdiff.
TUT130: Challenges in Storage I/O in Virtualization
Another nice one, but an emergency at work (printing down in a dorm, during finals week) distracted me heavily during the first half of it. Which resulted in the following note in my notes:
NPIV looks really nifty. Look into it.NPIV being how you can use fibre-channel zoning to zone off VM's, rather than HBA's. Highly useful. I also learned about a neat new thing called Virtual Fabrics. Virtual Fabrics work kind of like VLANS for fabrics. You can segregate your fabrics into fabrics that share hardware but nothing else. Handy if your, say, Solaris admins don't want you mucking about with their zoning, while saving money through consolidated hardware.
TUT216: OES2 SP1 Architectural Overview
There is a LOT of new stuff in SP1.
- It will include eDir 8.8.4 (8.8.3 will ship this summer sometime)
- NCP and eDir will be fully 64-bit
- OES2 SP1 will be based on SLES SP2, which will be releasing about the same time
- AFP Support
- AFP 3.1
- Uses Diffie-Helman 1 for password exchange, meaning the 8-character password problem is solved.
- Fully SMP-safe
- Has cross-protocol locking with NCP. CIFS doesn't have cross-protocol locking yet, but IIRC, Samba does
- Does not need LUM enabled users
- CIFS Support
- NTLMv1, but v2 is a possibility if enough people ask, so file those enhancement requests!!
- CIFS is separate from Samba, therefore can not be used in conjunction with Domain Services for Windows
- As with AFP, fully SMP safe
- EDir 8.8.4
- LDAP auditing enhanced
- "newer auth protocols", but they didn't say what.
TUT211: Enhanced Protocol Support in OES2 SP1
This is the session where they went into detail about the AFP and CIFS support. They said that netatalk, the existing AFP stack on Linux, gets really slow once you go over the 20 concurrent users. Whoa! I can soooo understand why Novell felt the need to make a new one.
- The 8 character password limit has been fixed! They now support DH1 for passing passwords.
- The 'afptcp' daemon can use one password protocol at a time, so you can only use DH1, or one of the other three I can't remember.
- Support for OSX 10.1 and 10.2 is scanty, and 10.5 is limited but users may not notice anyway.
- Passwords will be case sensitive.
- Kerberos will be in a future release
- Performance is faster than NetWare, partly due to the ability to multi-thread
- Can register services by way of SLP
- Only supports NSS for the time being, the other Linux file-systems will be a future feature.
- Can support 500 concurrent users, and 1000+ in the future. This fits our current AFP loads.
- We can configure more about how it works than we could on NetWare, such as how many worker threads to spawn.
- Has meaninful debug logs!
- Has a new command, 'afpstat' that works like 'netstat' for giving a snapshot of afp connections.
Tonight was the night formerly known as 'Sponsor Night,' but has a new name now that everyone who gets a booth is no longer a 'sponsor'. Some are sponsors, some are exhibiters. I can't keep track. Anyway, today was their party. "World of Novellcraft!" Homage to vid-gaming.
Lots of Wii, lots of Rock Band, some Halo, lots of women dressed in Renaissance Festival gear getting their pictures taken by the 90%+ male audience. I've blogged before about my ambivalence about Sponsor Night. I lasted until about 7, when I came back to the hotel.
Tomorrow I have an actual LUNCH BREAK in my schedule! Ooo! And
Labels: brainshare, edir, linux, netware, novell, OES, sysadmin
Monday, February 25, 2008
First OES2
This weekend I upgraded the one replica server running OES1-Linux to OES2-Linux. It already was at eDir 8.8.2 so the only real changes were to the base OS. It went rather well. The upgrade documentation provided by Novell was just fine. Really, a simple upgrade.
It being done on a Pentium III 1.2GHz machine meant it took a while. But very little in the way of complication. The one hitch was that it changed the certificate the NLDAP server loads to the default, which I didn't catch until a certain service we wrote failed. But that was a very easy fix.
It being done on a Pentium III 1.2GHz machine meant it took a while. But very little in the way of complication. The one hitch was that it changed the certificate the NLDAP server loads to the default, which I didn't catch until a certain service we wrote failed. But that was a very easy fix.
Saturday, January 19, 2008
Good migration
At home I just migrated the linux server to new hardware. This has to be one of the easiest migrations I've ever done for that service. Now just the obsessive tweaking needs doing, all the major functions are moved.
That server is running Slackware. I'm not using SuSE at home for a couple of reasons:
I got my first wireless access point in November of 2000. Way back then, they hadn't quite figured out all the short-cuts to cracking WEP so it required a certain amount of traffic to analyze. This was a Linksys B AP, and a Linksys wireless card. Together they had el-crappo for range (to today's standards).
With that in mind I segregated my network.
Internet <- Cisco 675 DSL -> Wired network <- Linux server -> Wireless network
Didn't have cable in our area yet back then. The Cisco handled everything I needed. Unfortunately, it was badly behaved. It had the nasty habit of ARPing through the whole dhcp range, one addr per second, continually.
At that point in time I had one wireless device. The always-on windows server was on the wired network, and the linux server configured to proxy things. So the only traffic on the wireless network was from my laptop; no ARP ARP ARP ARP ARP and no windows browse packets. In other words, it was a network that was hard to crack. Oh yeah, baby.
Fast forward a couple years. I move out here, we get cable instead of DSL.
Another year or two, and the 802.11b AP died so we moved to a G AP.
Another year, and I added a certain linux-based media server (wireless for long reasons) and my wife got a PowerBook.
The 10MB ethernet card in the back of that Linux machine (a Pentium 2 450MHz machine) was really... concerning me. Comcast is still under 10MB, but... it's the principle of the thing. It was a bloody ISA card for pete's sake.
So today I flattened the network. It's structured the same, but rather than have separate subnets I'm just using brctl to bridge the two; I like being able to easily sniff my wireless traffic. We no longer have an always-on Windows box. And WPA-PSK is a heckova lot harder to crack than WPA ever was. So, I figure it's safe. Plus, if the linux machine ever dies I only have to move one cable to get things back online.
Now the internet seems faster when browsing on the laptops. I guess that 10MB card was actually slowing things down a bit.
That server is running Slackware. I'm not using SuSE at home for a couple of reasons:
- I've been using Slack since college
- Diversity is good when figuring out how to run Linux
- Slackware doesn't have anything approaching YaST.
- Getting a new service online with Slackware takes about five times longer than it does with SuSE, but at the end of it you know how it bloody well works.
- It's easier to crib from existing config files that way.
I got my first wireless access point in November of 2000. Way back then, they hadn't quite figured out all the short-cuts to cracking WEP so it required a certain amount of traffic to analyze. This was a Linksys B AP, and a Linksys wireless card. Together they had el-crappo for range (to today's standards).
With that in mind I segregated my network.
Internet <- Cisco 675 DSL -> Wired network <- Linux server -> Wireless network
Didn't have cable in our area yet back then. The Cisco handled everything I needed. Unfortunately, it was badly behaved. It had the nasty habit of ARPing through the whole dhcp range, one addr per second, continually.
At that point in time I had one wireless device. The always-on windows server was on the wired network, and the linux server configured to proxy things. So the only traffic on the wireless network was from my laptop; no ARP ARP ARP ARP ARP and no windows browse packets. In other words, it was a network that was hard to crack. Oh yeah, baby.
Fast forward a couple years. I move out here, we get cable instead of DSL.
Another year or two, and the 802.11b AP died so we moved to a G AP.
Another year, and I added a certain linux-based media server (wireless for long reasons) and my wife got a PowerBook.
The 10MB ethernet card in the back of that Linux machine (a Pentium 2 450MHz machine) was really... concerning me. Comcast is still under 10MB, but... it's the principle of the thing. It was a bloody ISA card for pete's sake.
So today I flattened the network. It's structured the same, but rather than have separate subnets I'm just using brctl to bridge the two; I like being able to easily sniff my wireless traffic. We no longer have an always-on Windows box. And WPA-PSK is a heckova lot harder to crack than WPA ever was. So, I figure it's safe. Plus, if the linux machine ever dies I only have to move one cable to get things back online.
Now the internet seems faster when browsing on the laptops. I guess that 10MB card was actually slowing things down a bit.
Friday, November 30, 2007
OES2 SP1 timing
Novell just posted the third draft of their OES2 Best Practices guide. Which you can locate here. In that guide is this text:
Another 21 months of a 32-bit operating system on the single biggest storage consumer on campus. We'll have at least one hardware refresh before then for some of the nodes, and... boy I hope they have NetWare drivers for that. The very limited testing I did with NetWare-in-Xen was not encouraging from a performance stand-point. If it looks like I'll have to deploy that way for the next servers we get in the cluster, I'll have to do more real testing to characterize the performance hit (if any). The idea of a 64-bit memory space for file-caching makes me drool. Not getting it for 21 months is painful.
That said, if Novell releases the eDirectory enabled AFP server for OES2-Linux outside of the service-pack I could still make the 2008 window. That's our only dependency for SP1
Domain Services for Windows, which is scheduled to ship with OES 2 SP1 (currently scheduled for late 2008), will also offer some clear advantages."Late 2008" means they WILL NOT have SP1 out by August of 2008. This means that the upgrade of our 6 node cluster to OES will have to wait until 2009. Grrarrr!
Another 21 months of a 32-bit operating system on the single biggest storage consumer on campus. We'll have at least one hardware refresh before then for some of the nodes, and... boy I hope they have NetWare drivers for that. The very limited testing I did with NetWare-in-Xen was not encouraging from a performance stand-point. If it looks like I'll have to deploy that way for the next servers we get in the cluster, I'll have to do more real testing to characterize the performance hit (if any). The idea of a 64-bit memory space for file-caching makes me drool. Not getting it for 21 months is painful.
That said, if Novell releases the eDirectory enabled AFP server for OES2-Linux outside of the service-pack I could still make the 2008 window. That's our only dependency for SP1
Monday, November 19, 2007
I didn't realize it was this bad.
A while back Novell held an online survey about YaST usage. They've just released results.
Right at the top, in the demographics section are the results for the 'gender' question.
Ow. Women are 2.3%? Jeez.
These sorts of surveys are FAR from scientific. But still, such a STRONG bias is rather disheartening. I know the BrainShare crowd is somewhere between 4:1 to 6:1 Men-to-Women (don't have exact numbers). That said, most of the women I meet there are there for either Identity Management or GroupWise. The audiences for sessions on high Linux geekery (like for Clusters or HA computing) are... very male.
Just looking at that chart makes me wince. Yeesh.
Right at the top, in the demographics section are the results for the 'gender' question.
Ow. Women are 2.3%? Jeez.
These sorts of surveys are FAR from scientific. But still, such a STRONG bias is rather disheartening. I know the BrainShare crowd is somewhere between 4:1 to 6:1 Men-to-Women (don't have exact numbers). That said, most of the women I meet there are there for either Identity Management or GroupWise. The audiences for sessions on high Linux geekery (like for Clusters or HA computing) are... very male.
Just looking at that chart makes me wince. Yeesh.
Tuesday, October 09, 2007
Xen in 10.3
Because I couldn't get a good video driver working for it, I haven't spent much time in the new Xen. I believe it is Xen 3.1. And yes, it IS a lot faster on the network. Wow. It used to be painful, now it is improved quite a bit. I just patched the windows vm on my work machine, and the network transfer went really fast. Then I had to turn it off since I needed my linux desktop back.
And now I get to see how to convert a Xen disk-image into a vmware disk image. I know it can be done, but I haven't dug up the script or whatever.
And now I get to see how to convert a Xen disk-image into a vmware disk image. I know it can be done, but I haven't dug up the script or whatever.
Labels: linux, virtualization
Friday, October 05, 2007
openSUSE 10.3 is in
No problems, but one. The "nvidia in Xen" problem is back. The prior solution isn't working yet. Unresolved symbols. This could be a work-stopper, or the thing that makes me move all the way to VMWare.
Labels: linux, opensuse, virtualization
Tuesday, October 02, 2007
NCL 2.0 beta and Xen, pt 2
I now have server side and client side captures. The server side shows what's really going on. It is clear that those jumbos I talked about earlier are being disassembled in the Xen network stack. The client traces look similar to this
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
<- Ack
<- Ack
-> NCP to server
<- Ack
With variations on the order. The NCP to server packets are all jumbos. From the server side it looks a lot different. The same sequence from the server side:
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
What's more, the server sees a marked delay in packets between the <- Ack and the first -> NCP to server. On the client side the delays are between the -> NCP to server and the responding <- Ack. I interpret this to show a packet-disassembly delay in the Xen stack.
What I can't figure out is how are the jumbos getting on the network stack at all? The configured network interfaces (except for loopback) in the Dom0 all have MTU values of 1500. I suspect NCL throughput for higher record sizes will improve markedly if it didn't force the Xen layer to disassemble the jumbos. Overriding the MTU on an interface is something that can only be done in kernel-space (I think) which would point to the novfs kernel module.
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
<- Ack
<- Ack
-> NCP to server
<- Ack
With variations on the order. The NCP to server packets are all jumbos. From the server side it looks a lot different. The same sequence from the server side:
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
What's more, the server sees a marked delay in packets between the <- Ack and the first -> NCP to server. On the client side the delays are between the -> NCP to server and the responding <- Ack. I interpret this to show a packet-disassembly delay in the Xen stack.
What I can't figure out is how are the jumbos getting on the network stack at all? The configured network interfaces (except for loopback) in the Dom0 all have MTU values of 1500. I suspect NCL throughput for higher record sizes will improve markedly if it didn't force the Xen layer to disassemble the jumbos. Overriding the MTU on an interface is something that can only be done in kernel-space (I think) which would point to the novfs kernel module.
Labels: linux, novell, virtualization
Monday, October 01, 2007
NCL 2.0 beta and Xen
I found a good candidate for why the Novell Client for Linux 2.0-beta is so crappy in a Xen kernel. Take a look at this:
Frame 6 (4434 bytes on wire, 4434 bytes captured)
What the heck? What it should look like is this:
Frame 6 (1514 bytes on wire, 1514 bytes captured)
So I go to our network guys and ask, "Have we turned on jumbo frames anywhere?" No, we haven't. Anywhere. Which I pretty much knew, since we're not doing any iSCSI. So where the heck is that jumbo coming from? The only thing I can think of is that the sniffing layer I'm getting this at is above the layer that'd grab what actually hits the wire, and something between the sniffer and the wire is converting these jumbos to the normal 1514B ethernet MTU, and that's where my lag is coming from.
This is a case where I'd like to span a port and get a sniff of what actually hits the wire so I can compare.
Frame 6 (4434 bytes on wire, 4434 bytes captured)
What the heck? What it should look like is this:
Frame 6 (1514 bytes on wire, 1514 bytes captured)
So I go to our network guys and ask, "Have we turned on jumbo frames anywhere?" No, we haven't. Anywhere. Which I pretty much knew, since we're not doing any iSCSI. So where the heck is that jumbo coming from? The only thing I can think of is that the sniffing layer I'm getting this at is above the layer that'd grab what actually hits the wire, and something between the sniffer and the wire is converting these jumbos to the normal 1514B ethernet MTU, and that's where my lag is coming from.
This is a case where I'd like to span a port and get a sniff of what actually hits the wire so I can compare.
Labels: linux, novell, virtualization
Friday, September 28, 2007
Novell client for Linux, part 2
I'm doing a test with the vanilla openSUSE kernel and the results are VASTLY BETTER. A snippet:
This would be a lot easier if Wireshark would stop freezing hard when I try to save a capture.
KB reclen write rewrite read rereadCompare that with the earlier numbers for that record size and you can see the problem.
51200 256 9178 9189 9130 8898
KB reclen write rewrite read rereadSee? It has to be something in the Xen Dom0 environment.
51200 256 595 587 8551 8491
This would be a lot easier if Wireshark would stop freezing hard when I try to save a capture.
Novell Client for Linux
I'm running the beta of it, but keep in mind I'm also running it on openSUSE, which is not what it has been specifically designed for. That said, I do have some performance numbers. Yesterday I ran a very simple IOZONE test on a 50MB file. This isn't a great test since it fits entirely inside the server's cache. But I'm not worried about that, I just want to see how fast this code can peddle.
Performance was... not good. Unfortunately, right now I can't tell if that is a side effect of running it on openSUSE 10.2, inside a Dom0 Xen domain. I want to re-run it running the standard kernel and see if the performance also doth suck.
Performance was... not good. Unfortunately, right now I can't tell if that is a side effect of running it on openSUSE 10.2, inside a Dom0 Xen domain. I want to re-run it running the standard kernel and see if the performance also doth suck.
random randomAs you can see, performance at record sizes over 8 is not great for writes. Reads, on the other hand, are quite zippy. Still not as zippy as the Windows client, which I've seen get up to 11000 on those tests. But still, zippy. I don't know where the problem is. I did some sniffing to try and figure it out, but nothing really stuck out as a cause. I'm seeing some 160ms delays in ACKs, but they're coming from the server. I can't tell what condition of the client-side write is causing the delayed ACK. Need more testing.
KB reclen write rewrite read reread
51200 4 3259 3218 3875 4026
51200 8 5144 4925 5404 5215
51200 16 193 196 6980 6788
51200 32 593 599 8371 8309
51200 64 609 594 8213 8437
51200 128 589 590 8399 8432
51200 256 595 587 8551 8491
51200 512 598 595 8528 8439
51200 1024 596 588 8580 8295
51200 2048 594 596 8595 8542
51200 4096 597 609 8258 8548
51200 8192 595 599 8683 8683
51200 16384 608 599 8673 8585
Tuesday, September 25, 2007
The perils of a manual process
Yesterday I found the root cause of a rather perplexing problem. We had a user, happily for me one of the other sysadmins at WWU, who couldn't get their eDir password changed. No matter how many times he ran the identity management process, his AD PW would change, but eDir would not even though the success on the event was good.
A word of note:
We do not use Novell Identity Management. We've built our own. When Novell first came out with DirXML 1.0, we already had the foundation of what we have right now. So, when I talk about IDM, I'm actually referring to our own self-built system not Novell's IDM.
To troubleshoot, I ran many tests. The longest one was to turn on dstrace logging on the root replica server, and push changes to the object. I'd push a change, watch the logs, then parse through the log for the user's object.
To figure out what that is, I needed to sniff packets. PKTSCAN to the rescue. On the IDM server I turned off connections to all but the server holding the Master replicas of everything. Then on the master replica server I loaded PKTSCAN. I turned on sniffing, make the change, wait 5 seconds just to be safe, turn off the sniff, save the sniff, and load the sniff in Wireshark. The two cases I tested:
Looking at the details of T=WWU, I saw that it had an aux class associated with it. It was posixAccount. Thus, was I illuminated.
This particular sysadmin requested to have his account 'turned on for linux'. Which is code for having the posixAccount aux-class associated and the uid, gid, cn, and shell attributes added. This is still a manual process for us since requests are few and far between, though that is changing. It would seem that when I did it, I right-clicked on the wrong object. Whoopsie poo! Easily fixed, though.
I removed the aux-class from the tree root object, and suddenly... IDM changes started applying to the right object! Hooray! I think the IDM code was keying off of commonName rather than CN for some reason, which is why the aux-class got in the way.
A word of note:
We do not use Novell Identity Management. We've built our own. When Novell first came out with DirXML 1.0, we already had the foundation of what we have right now. So, when I talk about IDM, I'm actually referring to our own self-built system not Novell's IDM.
To troubleshoot, I ran many tests. The longest one was to turn on dstrace logging on the root replica server, and push changes to the object. I'd push a change, watch the logs, then parse through the log for the user's object.
- Changing it via LDAP made a sync.
- Changing it via the IDM did not make a sync.
- Changing it via iManager made a sync.
- Changing it via ConsoleOne on the IDM server made a sync
To figure out what that is, I needed to sniff packets. PKTSCAN to the rescue. On the IDM server I turned off connections to all but the server holding the Master replicas of everything. Then on the master replica server I loaded PKTSCAN. I turned on sniffing, make the change, wait 5 seconds just to be safe, turn off the sniff, save the sniff, and load the sniff in Wireshark. The two cases I tested:
- Change the concurrent connections attribute through IDM
- Change the concurrent connections attribute through ConsoleOne on the IDM server
Looking at the details of T=WWU, I saw that it had an aux class associated with it. It was posixAccount. Thus, was I illuminated.
This particular sysadmin requested to have his account 'turned on for linux'. Which is code for having the posixAccount aux-class associated and the uid, gid, cn, and shell attributes added. This is still a manual process for us since requests are few and far between, though that is changing. It would seem that when I did it, I right-clicked on the wrong object. Whoopsie poo! Easily fixed, though.
I removed the aux-class from the tree root object, and suddenly... IDM changes started applying to the right object! Hooray! I think the IDM code was keying off of commonName rather than CN for some reason, which is why the aux-class got in the way.
Friday, August 24, 2007
openSUSE news
They have a new news-portal site, which is nifty:
http://news.opensuse.org
They had a nice article today about the results of a recent desktop linux survey. Bucky had a nice bit of analysis about it too.
This is nice to see. As I've mentioned before, I'm using openSUSE 10.2 at work (and right now). I can't use SLED because we're not entitled to it, nor will my boss pay for it. That said, I probably could do what a co-worker is doing and run SLES10sp1 instead ;). OpenSUSE now has 10.3 beta 2 out, which I'm not going to test quite yet as I don't have a test system for it; I wish I did have one.
One of the nice things that'll be in 10.3 (or rather, not in) is they're doing away with zmd for updates, and using a libzypp based process instead. This cheers me, as I've had a lot of trouble with the zmd one. It's better than it was in 10.0/1, but still not good.
Also, of course, openSUSE code forms the basis for what'll eventually become SLED.
http://news.opensuse.org
They had a nice article today about the results of a recent desktop linux survey. Bucky had a nice bit of analysis about it too.
This is nice to see. As I've mentioned before, I'm using openSUSE 10.2 at work (and right now). I can't use SLED because we're not entitled to it, nor will my boss pay for it. That said, I probably could do what a co-worker is doing and run SLES10sp1 instead ;). OpenSUSE now has 10.3 beta 2 out, which I'm not going to test quite yet as I don't have a test system for it; I wish I did have one.
One of the nice things that'll be in 10.3 (or rather, not in) is they're doing away with zmd for updates, and using a libzypp based process instead. This cheers me, as I've had a lot of trouble with the zmd one. It's better than it was in 10.0/1, but still not good.
Also, of course, openSUSE code forms the basis for what'll eventually become SLED.
Wednesday, July 11, 2007
Novell Client for Linux beta 2.0 release on openSUSE
I have managed to get the new beta of the NCL 2.0 working on my openSUSE 10.2 workstation. This is very nice. Some nice details can be found here in the Novell support groups. My steps were rather similar.
See that little sliver of an icon between the magnifying glass and the vertical bar? That's the nwtray icon. It's about 2 pixels wide. If I can click on it I get the full NWTRAY menu just fine, but it's hard to hit.
The other problem is the "Novell Services" button in nautilus. When I click that button, it looks like gnome crashes. I haven't been able to find out where the dump traces are going so I don't know what's up with that. If I access the services from the 2-pixel wide NWTRAY things work just fine, though.
Throughput still sucks, though. The Windows client is still better for that. But... throughput is w-a-y better than using a WebDav connection! Progress!
- Install the referenced RPM. I did it with an "rpm -i [rpm-name]". Use the RPM for your processor type. I'm using 64-bit and it worked just fine for me.
- Run the "ncl-install" from the beta download.
See that little sliver of an icon between the magnifying glass and the vertical bar? That's the nwtray icon. It's about 2 pixels wide. If I can click on it I get the full NWTRAY menu just fine, but it's hard to hit.
The other problem is the "Novell Services" button in nautilus. When I click that button, it looks like gnome crashes. I haven't been able to find out where the dump traces are going so I don't know what's up with that. If I access the services from the 2-pixel wide NWTRAY things work just fine, though.
Throughput still sucks, though. The Windows client is still better for that. But... throughput is w-a-y better than using a WebDav connection! Progress!
Friday, June 08, 2007
EVEN MORE NIGH!
From what I can see, it's on the Red Carpet servers now!
SUSE-Linux-Enterprise-SDK-SP1
SUSE-Linux-Enterprise-Server-SP1
SUSE-Linux-Enterprise-Desktop-SP1
I wonder if I can register against it? Hmmm....
I wonder if I can register against it? Hmmm....
SLES 10 SP1 is nigh! Nigh!
There are a couple of highly interesting items available for download right now from download.novell.com.
SUSE Linux Enterprise On Microsoft's Virtual Hard Drive
iFolder 3.4 for SLED 10 SP1
Could we have SP1 out on Monday? Could OES2 (based on SLES10 SP1 code) be out Monday? We shall see, we shall see.
SUSE Linux Enterprise On Microsoft's Virtual Hard Drive
SUSE Linux Enterprise Server (SLES) on Microsoft's Virtual Hard Drive (VHD) is a VHD image file that contains the latest release of SUSE Linux Enterprise Server: SLES 10 SP1 with most available packages already installed. With this image you can run SLES 10 SP1 on your Microsoft Virtual Server 2005 R2.While not interesting to me in that I don't use VHD, this is reportedly a SLES 10 SP1 build. If they've felt the need to release this, then SP1 must be out really soon.
iFolder 3.4 for SLED 10 SP1
Again, we don't use iFolder, but this is the client that works with SP1. This is available for download right now.The iFolderTM 3.4 client for SUSE® Linux Enterprise Desktop 10 SP1 enables users to share their local files through a central Novell® iFolder 3.2 server. Users can create multiple iFolders, share each of the iFolders with other users, and specify each member's access right to the iFolder data. Users can also participate in iFolders that others share with them.
The iFolder 3.4 client for SUSE Linux Enterprise Desktop 10 SP1 is available for 32-bit (i586) and 64-bit (x86_64) architectures. The client consists of three modules: iFolder, Nautilus, and Simias. Each of the compressed download files contains the three modules for the specified architecture.
To use the client, the user must also have an iFolder account on a Novell iFolder 3.2 server.
Could we have SP1 out on Monday? Could OES2 (based on SLES10 SP1 code) be out Monday? We shall see, we shall see.
Monday, April 30, 2007
Quick hits from Linuxfest Northwest
Probably the biggest news, Ted Hagger is leaving Novell. Though the message says "March 24th", he said in session on Saturday, "Well, as of Wednesday I'm no longer with Novell." Which would imply that Tuesday April 24th was his last day. March 24th was the Saturday after BrainShare.
Whoa.
He's moving to a company that's doing Web 2.0 work. As that's soooo not my field, Ted is likely dropping off of my radar. He will not be doing any more Novell Open Audio.
Also, I was inspired by a session on OpenID to do a few things differently around here. I'm not sure we'll become and OpenID provider, but it is within the realm of possibility.
I learned more about Xen virtualization, which is nifty as I need to know that stuff.
Whoa.
He's moving to a company that's doing Web 2.0 work. As that's soooo not my field, Ted is likely dropping off of my radar. He will not be doing any more Novell Open Audio.
Also, I was inspired by a session on OpenID to do a few things differently around here. I'm not sure we'll become and OpenID provider, but it is within the realm of possibility.
I learned more about Xen virtualization, which is nifty as I need to know that stuff.
Friday, February 09, 2007
NetStorage and gnome davs::
I just figured out how to get NetStorage to work with openSUSE 10.2! You have to set NetStorage to 'cookieless mode'. Now I have access to my NetWare hosted volumes from openSUSE! It'd be better if I could direct mount them, much more efficient transfer protocols, but this will do until Novell releases the next Client for Linux with SLED10 sp1.
Friday, December 22, 2006
Other client news
My earlier message about the open audio podcast also included some information about the Novell Client for Linux. It still isn't quite there yet, and Jason Williams admitted as much in the podcast. However, he did share some news about the next version of the Novell Client for Linux due out with either OES2 or SLED10 sp1.
The RSA bits ended up being just a little bit too secure for a heterogeneous environment. For a pure NetWare/NDS environment it was great, arguably the most secure thing around at the time. Since then Novell has realized that password synchronization between different authentication sources is a key technology in and of itself, which required that password encryption be reversible. Which the RSA stuff wasn't. Thus, the introduction of Simple passwords, and ultimately Universal passwords; both of which are less secure than the RSA methods, but still secure enough.
A lot of companies have moved to Universal passwords, but Novell still has to support the RSA-style login methods through the client. Therefore, the RSA-libraries have to be distributed with the client, and that makes it impossible to open-source without RSA's approval. Which isn't coming any time soon. There may be other 3rd party licensed technology in the client, but I can't remember who else may be involved.
It may be possible to create a true open-source client that just doesn't speak the proprietary protocols, though I strongly suspect that doing so will require significant reconfiguration of Open Enterprise Server. If not significant re-engineering. This is a legacy issue.
- NCL is build using AutoBuild, but a private AutoBuild.
- The NCL will never be open-sourced because it has to use proprietary third party modules that Novell does not have the rights to open-source. One of the key modules are the RSA modules.
- The new NCL will be able to auto-detect the kernel being used and will be able to automatically generate the required kernel modules (novfs and others) when kernel version change. Really nifty!
- Introducing Gnome integration for Novell volumes. They already have the KDE version out. This will allow you to do some of the things you can do right now in Windows Explorer, only on Gnome and KDE.
The RSA bits ended up being just a little bit too secure for a heterogeneous environment. For a pure NetWare/NDS environment it was great, arguably the most secure thing around at the time. Since then Novell has realized that password synchronization between different authentication sources is a key technology in and of itself, which required that password encryption be reversible. Which the RSA stuff wasn't. Thus, the introduction of Simple passwords, and ultimately Universal passwords; both of which are less secure than the RSA methods, but still secure enough.
A lot of companies have moved to Universal passwords, but Novell still has to support the RSA-style login methods through the client. Therefore, the RSA-libraries have to be distributed with the client, and that makes it impossible to open-source without RSA's approval. Which isn't coming any time soon. There may be other 3rd party licensed technology in the client, but I can't remember who else may be involved.
It may be possible to create a true open-source client that just doesn't speak the proprietary protocols, though I strongly suspect that doing so will require significant reconfiguration of Open Enterprise Server. If not significant re-engineering. This is a legacy issue.
Monday, November 06, 2006
Vendor lock-in, my reality
Freedom from vendor lock-in is one of the louder themes in the criticism in this post Novell/Microsoft-deal world. Free and Open Source Software (FOSS, learned that one this week) is all about avoiding vendor lock-in. Linux comes in the wide flavors it does so that vendor lock-in doesn't have to happen.
Here is how I view vendor lock-in as a part of my job. This is coming from a system administrator who manages in a largish regional enterprise. Both this job and OldJob didn't have significant WAN links, but we did have well over 1000 users to play with.
Both my old job and my new job saw significant savings by sole-sourcing server hardware. OldJob was a Dell shop pretty completely, with a very, very few Compaq hold-outs. Here in Technical Services we're a very solid HP shop, with some Dell thrown in as we inherit systems from other departments. Both old and new jobs had some Solaris around for various things. At OldJob we didn't use OpenManage much at all. Here, we're not really using OpenView.
Both companies realized that whiteboxing, building servers from component parts and supporting things internally, was a losing idea at the scales both jobs built out at. Having a single vendor support us for server hardware eased support costs and made the internal knowledge-base required to support our hardware much less complex.
OldJob used to be a Compaq shop, but dropped it in favor of Dell due to and I quote directly, "all of that proprietary crap." The fact that Dell was a lot cheaper at the time also helped significantly. As I understand it, Technical Services was that rarity, a HP shop. The Compaq merger was viewed with some dismay in certain parts. This is why we have some HP LH3's stacked against one wall.
As for operating systems, OldJob and NewJob had different ideas. One of the reasons I left OldJob was a decision from the top of IT management to unify on a single Directory; Microsoft's. How that would interact with GroupWise, which was VERY firmly established in the enterprise and not being moved out, was a complete mystery to us techs who would eventually be asked to make it work. Accompanying this decision was the directive to start migrating the NetWare servers out in favor of Microsoft Windows. They were reducing support costs by reducing the number of OSs in the datacenter.
WWU works differently. They've had a 'best of breed' philosophy for services for some time, and NetWare is still king for File Serving performance. Solaris was king for Oracle for a long time, though that throne is in a bit of question at the moment. Linux has started creeping in as an application server a few places, so far just web-servers (the web-server that drives the time-card web front-end is Linux, with a Solaris/Oracle back end).
One of the differences between my old environment and this environment is budgetary. OldJob had a strict three year replacement cycle for servers, that they were thinking of extending to 3.5 or 4 yeaers to better handle server swaps (3-6 month stage up and migration, 3-6 month demigration and stage down). WWU plans on keeping servers in some form of production for 5 years, though the last one to two years may be as a dev server rather than mainline production. The same sort of pressures happen on the software we use on the servers, as we're more likely to use OSS than we were at my old job.
That said, when it comes to package management on the Solaris and Linux servers we rarely go outside of the vendor for packages. I know we compile Samba from source on Solaris, but then we're using an old Solaris version that doesn't do what we need out of the box very well. If it isn't on the Solaris or SLES9 repositories (we don't have any SLES10 in yet), we probably won't deploy on that.
Our OS vendors are Microsoft, Novell, and Solaris. Other departments use Gentoo, Slackware, and I'm sure some Ubuntu and Red Hat.
All that said, we do deal with, and embrace, vendor lock-in. We do it in hardware. We do it in software, as our Help Desk software only runs on a Windows/IIS stack (though can do MSSQL or Oracle as a DB source). We do it in file serving OS, as it would be a royal pain to use anything but an NCP server from Novell on NetWare (even OES-Linux presents some problems). We do it in small-office databases, which are all housed on an MS-SQL server (we can do oracle, but it is a pain and the processes are not well established or documented).
We also embrace diversity. Our HelpDesk app requires Windows/IIS, but our student email web-access app required Apache/PHP. Web-serving is perhaps our most diversified environment, as we are widely deployed in both Apache and IIS based technologies. Several main line applications are java driven, others are driven by ASP, still others use PHP.
When it comes to an OS we'll use on mainline applications, we have to have enterprise support. This means buying our OS from a firm that can provide 24x7x365.25 support. This reduces the number of firms we can purchase Linux support from. Additionally, we need some form of patch management system. NetWare is the least well supported when it comes to patch management, as it is a 100% manual process, happily it doesn't need a lot of attention. We won't do NetWare-style patch management on Linux, as that method doesn't scale. In effect we're limited to Red Hat or Novell for Linux, and as we already have a contract with Novell for NetWare support that's where we went. Furthering our lock-in with Novell.
So vendor lock in is really a fact of life here. I appreciate the fact that I can toss a Slackware server in amongst the servers and have a fair chance of making it work if I really need it to. But that'll be emergency processing, not standard procedure.
I'll leave what the Novell/Microsoft deal means in terms of the viability of Linux in the enterprise for another post.
Tags: novell, linux
Here is how I view vendor lock-in as a part of my job. This is coming from a system administrator who manages in a largish regional enterprise. Both this job and OldJob didn't have significant WAN links, but we did have well over 1000 users to play with.
Both my old job and my new job saw significant savings by sole-sourcing server hardware. OldJob was a Dell shop pretty completely, with a very, very few Compaq hold-outs. Here in Technical Services we're a very solid HP shop, with some Dell thrown in as we inherit systems from other departments. Both old and new jobs had some Solaris around for various things. At OldJob we didn't use OpenManage much at all. Here, we're not really using OpenView.
Both companies realized that whiteboxing, building servers from component parts and supporting things internally, was a losing idea at the scales both jobs built out at. Having a single vendor support us for server hardware eased support costs and made the internal knowledge-base required to support our hardware much less complex.
OldJob used to be a Compaq shop, but dropped it in favor of Dell due to and I quote directly, "all of that proprietary crap." The fact that Dell was a lot cheaper at the time also helped significantly. As I understand it, Technical Services was that rarity, a HP shop. The Compaq merger was viewed with some dismay in certain parts. This is why we have some HP LH3's stacked against one wall.
As for operating systems, OldJob and NewJob had different ideas. One of the reasons I left OldJob was a decision from the top of IT management to unify on a single Directory; Microsoft's. How that would interact with GroupWise, which was VERY firmly established in the enterprise and not being moved out, was a complete mystery to us techs who would eventually be asked to make it work. Accompanying this decision was the directive to start migrating the NetWare servers out in favor of Microsoft Windows. They were reducing support costs by reducing the number of OSs in the datacenter.
WWU works differently. They've had a 'best of breed' philosophy for services for some time, and NetWare is still king for File Serving performance. Solaris was king for Oracle for a long time, though that throne is in a bit of question at the moment. Linux has started creeping in as an application server a few places, so far just web-servers (the web-server that drives the time-card web front-end is Linux, with a Solaris/Oracle back end).
One of the differences between my old environment and this environment is budgetary. OldJob had a strict three year replacement cycle for servers, that they were thinking of extending to 3.5 or 4 yeaers to better handle server swaps (3-6 month stage up and migration, 3-6 month demigration and stage down). WWU plans on keeping servers in some form of production for 5 years, though the last one to two years may be as a dev server rather than mainline production. The same sort of pressures happen on the software we use on the servers, as we're more likely to use OSS than we were at my old job.
That said, when it comes to package management on the Solaris and Linux servers we rarely go outside of the vendor for packages. I know we compile Samba from source on Solaris, but then we're using an old Solaris version that doesn't do what we need out of the box very well. If it isn't on the Solaris or SLES9 repositories (we don't have any SLES10 in yet), we probably won't deploy on that.
Our OS vendors are Microsoft, Novell, and Solaris. Other departments use Gentoo, Slackware, and I'm sure some Ubuntu and Red Hat.
All that said, we do deal with, and embrace, vendor lock-in. We do it in hardware. We do it in software, as our Help Desk software only runs on a Windows/IIS stack (though can do MSSQL or Oracle as a DB source). We do it in file serving OS, as it would be a royal pain to use anything but an NCP server from Novell on NetWare (even OES-Linux presents some problems). We do it in small-office databases, which are all housed on an MS-SQL server (we can do oracle, but it is a pain and the processes are not well established or documented).
We also embrace diversity. Our HelpDesk app requires Windows/IIS, but our student email web-access app required Apache/PHP. Web-serving is perhaps our most diversified environment, as we are widely deployed in both Apache and IIS based technologies. Several main line applications are java driven, others are driven by ASP, still others use PHP.
When it comes to an OS we'll use on mainline applications, we have to have enterprise support. This means buying our OS from a firm that can provide 24x7x365.25 support. This reduces the number of firms we can purchase Linux support from. Additionally, we need some form of patch management system. NetWare is the least well supported when it comes to patch management, as it is a 100% manual process, happily it doesn't need a lot of attention. We won't do NetWare-style patch management on Linux, as that method doesn't scale. In effect we're limited to Red Hat or Novell for Linux, and as we already have a contract with Novell for NetWare support that's where we went. Furthering our lock-in with Novell.
So vendor lock in is really a fact of life here. I appreciate the fact that I can toss a Slackware server in amongst the servers and have a fair chance of making it work if I really need it to. But that'll be emergency processing, not standard procedure.
I'll leave what the Novell/Microsoft deal means in terms of the viability of Linux in the enterprise for another post.
Tags: novell, linux
