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
Tuesday, August 28, 2007
ZenCM (a.k.a. Zen 10)
We're taking a look at ZenCM right now, as it's the Zen that supports Vista. I saw quite a lot about it back at Brainshare, so I have some expectations. Now that it is out, there is a manual out. We like manuals. They tell us what to expect.
Some quick hits on differences that'll cause us to do things differently from previous Zen versions:
There is also internal disgruntlement about the abandonment of edir as the policy repository, but I understand the sound business reasons for it. The loss of the ability to have NetWare be the file-source for application installs is also something that is causing grumbling, as that's the infrastructure that's well built for large scale deployments. The fact that we need yet another server for this is also causing grumbling, though in the end we'll be using the server that was slated to be the real server for the Zen Asset Inventory, as its beefy enough to handle it (we think).
And then the imaging question... we've not been using Zen's imaging because we've been using another product. However, that other product plays hobb with Workstation Import, and from the sounds of it that'll still be a problem with ZenCM. So, no device-based policies for us.
All in all, we'll end up going with it because 1) it's free to us, and 2) we've always been using it. That said, there will be a push to use the built-in AD tools as they are perceived to be less clunky. No agent to install, that sort of thing.
Some quick hits on differences that'll cause us to do things differently from previous Zen versions:
- No NetWare support, so we'll need at least one new server to drive this thing.
- Application deployment won't work with NetWare as a file source, so all those MSI's will have to be hosted on Windows somewhere (no Linux support yet, though that's probably SP1 stuff).
- Inventory has been rolled into the central product, so no need for a separate Inventory server like the past (the past product was the Inventory side of Zen Asset Management. ZAM now is just Asset Management).
- No AXT-based installs, just MSI and Simple Application.
- The MSI installs will FORCE us to start looking at ApplicationStudio, whether we like it or not.
- Introduces a single point of failure for Zen policy, as it no longer uses eDir for a policy repository, and instead uses the ZenCM server. Which in our case will be a single server, as we're not $$$ enough for two, nor do our users segregate into large chunks well.
There is also internal disgruntlement about the abandonment of edir as the policy repository, but I understand the sound business reasons for it. The loss of the ability to have NetWare be the file-source for application installs is also something that is causing grumbling, as that's the infrastructure that's well built for large scale deployments. The fact that we need yet another server for this is also causing grumbling, though in the end we'll be using the server that was slated to be the real server for the Zen Asset Inventory, as its beefy enough to handle it (we think).
And then the imaging question... we've not been using Zen's imaging because we've been using another product. However, that other product plays hobb with Workstation Import, and from the sounds of it that'll still be a problem with ZenCM. So, no device-based policies for us.
All in all, we'll end up going with it because 1) it's free to us, and 2) we've always been using it. That said, there will be a push to use the built-in AD tools as they are perceived to be less clunky. No agent to install, that sort of thing.
Monday, June 18, 2007
New Novell releases
Looks like Novell pushed several products out the door late Friday:
NCL 2.0 is interesting since the current version is v1.2. The full rev of the version suggests that they made marked improvements to it. I have noticed that they offer both 32bit and 64 bit versions of the client, which I don't think 1.2 had.
- SP1 for SLES and SLED 10
- The public beta for ZenCM
- The public beta for the Novell Client for Linux 2.0
NCL 2.0 is interesting since the current version is v1.2. The full rev of the version suggests that they made marked improvements to it. I have noticed that they offer both 32bit and 64 bit versions of the client, which I don't think 1.2 had.
Thursday, March 15, 2007
ZEN Pulsar has a name
http://www.novell.com/coolblogs/?p=792
and
http://www.novell.com/news/press/item.jsp?id=1306
It is, wait for it...
Novell ZENworks Configuration Management!
One nifty feature, long rumored:
We'll hear a lot more about it next week at BrainShare, I'm sure. One thing is clear, and that's this version of Zen is Windows-desktop only for the time being. Linux will come later, again we'll learn more next week. ZEN Asset Management is still a different product, as is Patch Management. No surprise there, as both products are repackaged third-party apps.
and
http://www.novell.com/news/press/item.jsp?id=1306
It is, wait for it...
Novell ZENworks Configuration Management!
One nifty feature, long rumored:
With native integration for both Microsoft* Active Directory* and Novell® eDirectoryTMI've heard that ZEN Pulsar would have its own internal database for things like application objects and images. I guessed this was due to eventual AD support, but, hey, there it is!
We'll hear a lot more about it next week at BrainShare, I'm sure. One thing is clear, and that's this version of Zen is Windows-desktop only for the time being. Linux will come later, again we'll learn more next week. ZEN Asset Management is still a different product, as is Patch Management. No surprise there, as both products are repackaged third-party apps.
Labels: brainshare, novell, zenworks
Monday, February 26, 2007
Zen asset inventory
We're in the process of rolling out Zen Asset Inventory 7.5. It's going OK, about 600 workstations imported so far. The Collection Server is a 4 proc box, and was quite busy this morning. Once all 2000-odd workstations get in, it's going to be busy a lot more often. We're most likely getting a new server for that role at some point. This is the only CPU-bound product I've seen in a while! Pretty much everything else we run is I/O bound in some way. Kinda nifty.
Which also means that this is not a very virtualization-friendly product. This'll be running bare-iron, thank you.
Which also means that this is not a very virtualization-friendly product. This'll be running bare-iron, thank you.
Labels: zenworks
Wednesday, February 21, 2007
Novell Open Audio: Zen for Vista
Novell Open Audio (podcasts) had a session on Zen and Vista. Here are the main points I got out of it.
- DLU on Vista will work within the Novell client
- 32 & 64bit
- Will use the Common Authentication Service to tie into auth.
- Client will still allow 'admin' level access for installing software while user remains general.
- NAL window & on desktop still supported
- Will have native MSI support only, and getting rid of 'snapshot' methods.
- MSI is defacto standard, and all Vista software comes via MSI
- MSI packaging products still in Zen
- Conversion tools to migrate snapshot Apps to MSI Apps
- Simple changes (reg keys, short cuts, file edits) still there, just no AXT support
- Vista by necessity introduces a very different Zen architecture. Still WinXP/2K compatible, though.
- Can run as a separate environment from Zen 7. This facilitates migration.
- Separate directory store for Zen stuff. Uses eDir for associations and the like. Application Object storage will be outside of eDir.
- Brainshare: Wednesday keynote will be big Zen demo.
Monday, January 29, 2007
An incompatibility
I've been working on Zen Asset Management 7.5 the past few days. In the process I discovered a rather significant incompatibility with the client. Well, significant for me since it'll make client testing harder.
When run on a Windows XP virtual machine running on Xen 3.0.3 that comes with openSUSE 10.2, it causes the clock in the VM to slow w-a-y down. On the order of 1 tick per 30 ticks on the host machine slow. This makes it unusable in a rather significant way.
It also is completely unfixable! Running Windows in a full VM in Xen on openSUSE 10.2 is an unsupported operation. I have the CPU for it, and it runs pretty well in every other way. But something the inventory process does causes some Xen emulation to go 'poink' in a bad way. It is so bad that even after the VM is powered off and the BIOS is putting the virtual machine to rest, it STILL takes a very long time for the VM to unload. No idea where to report this one.
In general, the product looks interesting. Getting it rolled out everywhere will take a lot of work. Plus, for some reason it isn't accepting my license code. But that's something that can be fixed with a call in to Novell.
When run on a Windows XP virtual machine running on Xen 3.0.3 that comes with openSUSE 10.2, it causes the clock in the VM to slow w-a-y down. On the order of 1 tick per 30 ticks on the host machine slow. This makes it unusable in a rather significant way.
It also is completely unfixable! Running Windows in a full VM in Xen on openSUSE 10.2 is an unsupported operation. I have the CPU for it, and it runs pretty well in every other way. But something the inventory process does causes some Xen emulation to go 'poink' in a bad way. It is so bad that even after the VM is powered off and the BIOS is putting the virtual machine to rest, it STILL takes a very long time for the VM to unload. No idea where to report this one.
In general, the product looks interesting. Getting it rolled out everywhere will take a lot of work. Plus, for some reason it isn't accepting my license code. But that's something that can be fixed with a call in to Novell.
Labels: opensuse, virtualization, zenworks
Monday, January 22, 2007
Busy week
Last week was interesting. I spent most of it hacking on the new spam appliances. Then we had another virus outbreak. A bad one. For a first-hand view of what happened read this. Due to a vacation on Friday, I wasn't directly involved in this one to any significant degree. Normally, ferreting out root-kits is right up my alley. Instead, I was have routine maintenance performed on certain small animals in my house.
As this is the second incident of a Symantec worm, it makes it especially galling. The machines that got infected were all ones that got missed during the last post-worm remediation. Unfortunately, certain computer labs did not have the new AV software updated on their images so they'll be vulnerable for a while; revising the lab image during session is apparently a major undertaking. I have been tasked with assessing with an assumption of eventually installing Zen Asset Management in an effort to allow us to identify 'non-compliant' machines when something like this happens in the future.
The go-ahead decision rests with the Vice Provost, which itself should provide an interesting insight into the new guy. This isn't the first time an inventory solution has been proposed. The previous Vice Provost had a low tolerance for back-talk from the Deans, so if enough Deans complained about the new whatever-it-is he usually backed down from supporting it. From the sounds of it, the new Vice Provost wants this capability quite badly, so we shall see how the cards fall.
As this is the second incident of a Symantec worm, it makes it especially galling. The machines that got infected were all ones that got missed during the last post-worm remediation. Unfortunately, certain computer labs did not have the new AV software updated on their images so they'll be vulnerable for a while; revising the lab image during session is apparently a major undertaking. I have been tasked with assessing with an assumption of eventually installing Zen Asset Management in an effort to allow us to identify 'non-compliant' machines when something like this happens in the future.
The go-ahead decision rests with the Vice Provost, which itself should provide an interesting insight into the new guy. This isn't the first time an inventory solution has been proposed. The previous Vice Provost had a low tolerance for back-talk from the Deans, so if enough Deans complained about the new whatever-it-is he usually backed down from supporting it. From the sounds of it, the new Vice Provost wants this capability quite badly, so we shall see how the cards fall.
Labels: zenworks
Wednesday, September 06, 2006
Technology is cooooool
I just worked out a REALLY NEAT trick to help with managing my benchmarking clients. I figured something like this is possible, but actually seeing it work was one of those moments that make what I do so fun. I came real close to shouting, "I am the zombie master," but I held off. Just.
Anyway, the trick:
The jobs all seem to start within 30 seconds of the scheduled time. This doesn't seem to be due to differences in the workstation clocks, on checking those are all within 3 seconds of 'true', rather the Workstation Manager task polling interval. I wish I could get true 'everyone right now' performance, but that's not possible without w-a-y more minions.
On the 'large number of sub-directories' test, the early jumpers seemed to get a continued edge over their late starters. The time to create directories for the early jumpers was consistantly in the 3-5ms range, where the late jumpers were in the 10-13ms range. Significant difference there. And some started fast and became slow, so there is clearly some threshold involved here beyond just the server dealing with all those new directory entries. CPU load on the NetWare box (what I have staged up first) during the test with 32 clients creating and enumerating large directories was in the 55-70% range. That load is spread equally over both CPUs, so those bits of NSS are fully MP enabled.
Tags: benchmarking, zenworks
Anyway, the trick:
- Make sure all the clients are imported as Workstation Objects.
- Create a Workstation Group, and add all of the clients into it.
- Add the newly created Workstation Group as a R/W trustee of the volume I'm benchmarking against. This allows the workstations as themselves, not users, to write files.
- Create a Workstation Policy, associate it to the group.
- In the Workstation Policy, create a Scheduled Task. Point it at the batchfile I wrote that'll map a drive to the correct volume, run the tests, and clean up.
- Modify the schedule so it'll run at a specific time, making sure to uncheck the 'randomize' box.
- Force a refresh of the Policies on the clients (restarting the Workstation Manager service will do it).
The jobs all seem to start within 30 seconds of the scheduled time. This doesn't seem to be due to differences in the workstation clocks, on checking those are all within 3 seconds of 'true', rather the Workstation Manager task polling interval. I wish I could get true 'everyone right now' performance, but that's not possible without w-a-y more minions.
On the 'large number of sub-directories' test, the early jumpers seemed to get a continued edge over their late starters. The time to create directories for the early jumpers was consistantly in the 3-5ms range, where the late jumpers were in the 10-13ms range. Significant difference there. And some started fast and became slow, so there is clearly some threshold involved here beyond just the server dealing with all those new directory entries. CPU load on the NetWare box (what I have staged up first) during the test with 32 clients creating and enumerating large directories was in the 55-70% range. That load is spread equally over both CPUs, so those bits of NSS are fully MP enabled.
Tags: benchmarking, zenworks
Labels: benchmarking, zenworks
