Subscribe: Logical Blog
Added By: Feedage Forager Feedage Grade B rated
Language: English
boot  configuration  ethernet  genunix org  install  numbers  opensolaris  org  server  servers  site  solaris  step  sun  tanku  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Logical Blog

Logical Blog

Solaris, OpenSolaris, Solaris on x86 and AMD64. Software developement on Solaris. Building or modifying commodity hardware to run Solaris on. Suns business strategies - strengths and weaknesses. Suggestions on how to build a better/stronger Sun Micros

Updated: 2014-10-03T01:48:44.214-05:00


hype versus reality


Like every engineer, I have to admit, upfront, that I have a limited tolerance to spin-meistering and marketing terminology. I find it boring, repetitive, tiring and annoying. It's also totally predictable - after you identify the marketing speakwords, aka buzzwords, its really annoying to see them over-used again and again and again and again - you get the picture. Most engineers can relate to this. The flip-side is that a certain amount of buzzwords replication actually works! OK - while I don't pretend to understand this phenomenon, I'll buy into it, based on anecdotal evidence. But... there is a point where hype and buzzword usage crosses my personal line-in-the-sand. I guess every technocrat has there own line-in-the-sand.That line, in my case, is where hype and buzzwords go from being hype, that really can't be verified and validated, to where it is totally bogus and unbelievable. In fact, I'll go further and state that, in some extreme cases, it can be plain dumb and/or possibly dishonest. Such is the case with Marc Hamiltons blog entry which states that the indiana project preview had seen 100,000 downloads in less than 72 hours. Why did I think that this number was just plain wrong? Because, I had an email exchange with Jesse Silver of Sun and he asked me if I could provide download numbers for the Project Indiana Developer Preview (filename in-preview.iso) that we were mirroring on and he told me to expect "big numbers". So I asked him, "what do you mean by big numbers?" and he said that they had seen over 100,000 downloads from I was curious - because, my initial reaction, was that I did'nt (personally) feel that there was this level of interest in Indiana - particularly since the marketing team had not released it under the widely expected name of Project Indiana, but instead, had chosen to rename/re-brand it, to the OpenSolaris Developer Preview - which no-one, including me, really expected. Well, after taking a look at's numbers: we had shipped 690 copies at that time (Mon Nov 5 11:52:54 PST 2007), I just did'nt see that level of interest. After a quick back-of-the-napkin calculation, I knew those numbers were just plain wrong - and I advised Jesse that I felt that those numbers were flawed. Why? Well, for the answer, take a look at the following email I sent to Marc Hamilton (3 days) later in the week after I noticed his blog entry (referred to in a post to one of the OpenSolaris mailing lists which prompted me to read it):--------- begin Marc Hamilton email -----------Date: Thu, 8 Nov 2007 10:22:09 -0600 (CST)From: Al Hopper To: Marc Hamilton Subject: 100k download - hard to believeHi Marc,I saw your recent blog[1] and the number you quoted for Project Indiana downloads (100,000) does not look reasonable to me. A "back-of-the-napkin" calculation reveals that for 100,000 downloads of 660226048 bytes per iso image, delivered over 72 hours, you'd be pushing over 2Gbits/Sec to the 'net. From a quick test of, it looks like you've got a 5Mbit/Sec cap on your connection (my best techguess).I had an earlier email "conversation" with Jesse Silver - where he asked me for our stats[2] and quoted his download numbers. I expressed scepticism that his numbers were accurate - suggesting that they may have counted the number of download transactions from the http access logs, rather than accumulating a count of the bytes transferred per in-preview.iso transacation and dividing the result by 660226048 (the size of the iso image). As of about 1 hour ago, we've shipped 808 copies of in-preview.iso.I would suggest that you update your blog ASAP.Comments welcome.[1][2] we are providing downloads of the in-preview.iso file--------- end Marc Hamilton email -----------I did'nt receive any feedback from Marc 28+ hours later - hence this blog.Should inaccurate hype be allowed to go unchallenged? What do you think?PS: screen capture of Marc Hamilton b[...]

Setup ZFS boot for Build 72


This cheat sheet will use a very simple and minimal PXE boot to help you setup a machine with ZFS boot and SXCE build 72 (and later). In all, from scratch, you should be able to complete this entire process in about one hour! We make the following assumptions:the install server is on the install network at install server is using a ZFS based filesystem with a pool called tanku. The users home directory is also in this pool at /tanku/home/althe target machine has ethernet address: 00:e0:81:2f:e1:4fthere are no other DHCP servers active on the install networkVerify that your ethernet interface supports PXE boot. Most systems do - except for low-end ethernet cards that don't have an option ROM. Determine the ethernet address of the interface you'll be using for PXE boot. Make a note of this address.Download Lori Alts/Dave Miners ZFS boot tools:wget - the date should be 20070418. Unzip and untar them - in this case they'll end up in /tanku/home/al/zfsboot/20070418(aka ~al/zfsboot/20070418)cdmkdir zfsbootcd zfsbootbunzip2 -c zfsboot-kit-20060418.i386.tar.bz2 | tar xvf -Notice that the directory name has been changed to 20070418. Find and read the README file. But don't spend too much time studying it. This cheat sheet will tell you what to do.On the install server setup a ZFS bootable netinstall image for b72mkdir /mnt72chown root:sys /mnt72chmod 755 /mnt72# FYI only: /solimages is an NFS mountlofiadm -a /solimages/sol-nv-b72-x86-dvd.isoAssumes that lofiadm returned "/dev/lofi/2"mount -F hsfs -o ro /dev/lofi/2 /mnt72zfs create tanku/b72installzfszfs set sharenfs='ro,anon=0' tanku/b72installzfscd /mnt72/Solaris_11/Tools./setup_install_server /tanku/b72installzfscd /tanku/home/al/zfsboot/20070418The next step takes around 13 minutes (why?)ptime ./patch_image_for_zfsboot /tanku/b72installzfsRemove the DVD image mount and cleanupumount /mnt72lofiadm -d /dev/lofi/2Verify that you can mount /tanku/b72installzfs on another machine as a quick test. Best to check this now than try to trouble shoot it later. Use a mount command similar to:mount -F nfs -o ro,vers=3,proto=tcp /mntNow cd to the Tools subdirectory in the prepared zfs boot area - in this case /tanku/b72zfsinstallcd /tanku/b72installzfs/Solaris_11/ToolsGenerate the target client files:./add_install_client -d -e 00:e0:81:2f:e1:4f -s i86pcYou'll see instructions to add the client macros (something) like:If not already configured, enable PXE boot by creatinga macro named 0100E0812FE14F with:Boot server IP (BootSrvA) : file (BootFile) : 0100E0812FE14FUsing the screen-by-screen guide at at step 5 entitled Configure and Run the DHCP Server , setup the DHCP server and add the required two macros. NB: Ignore everything up to step 5. You don't need any of it!At step 5.n, "n. Type the number of IP addresses and click Next." you should consider adding more than two addresses, in case something else on this network (unexpectedly) requests a DHCP lease.Now add the two macros and use the name 0100E0812FE14F Note Well: the macro must have the correct name. Verify that the tftp based files are available. Again - a quick test now will save you a bunch of trouble shooting time down the road.df | grep tftpIt should look something *like* this:/tanku/b72installzfs/boot 260129046 3564877 256564169 2% /tftpboot/I86PC.Solaris_11-2Test that the tftp files can be successfully retrieved via tftp:$ cd /tmp$ tftp> get 0100E0812FE14FReceived 134028 bytes in 0.0 secondstftp> quitDon't forget to cleanup:rm /tmp/0100E0812FE14FEnable FTP on your boot server to allow snagging the zfs boot profile file:svcadm enable ftpChange your password before you dare use FTP. Remember to use a disposable password - because it can be sniffed on the LAN. After we're finished using FTP,[...]

Genunix.Org is Alive

2005-06-19T15:31:26.006-05:00 equipment with the N2120 staged for the camera only Take a look at GenUnix.Org There's not much content there now, beyond a mirror of the OpenSolaris launch files and some video from the first Open Solaris User Group meeting; but that'll change in the future. Cyril Plisko has an operational SubVersion (SVN) source repository hosted at the site.How got started (Part 1 of 2)Early in May, I got the idea to host an OpenSolaris Community/Mirror site. First off was to leave a message for Paul Vixie of Internet Systems Consortium - because I know that they currently host and a bunch of other, successful, Open Source projects. I wanted to add OpenSolaris to that list.Within a week I had been contacted by Peter Losher and we got an OK to proceed. I could hardly believe it - access to a clean one gigabit connection to the internet with the rackspace, power, cooling and bandwidth sponsored by ISC.Next I needed to scrounge up some equipment. We (at Logical Approach) decided to sponsor the site with a maxxed out V20Z: two 146 gigabyte drives, 8 gigabytes of memory and two AMD 252 (2.6GHz) Opteron processors. This would ensure that a site would go online and indicate our committment to this project. However I was reluctant to bringup the site to support the upcoming launch of OpenSolaris, with just one server. I wanted high performance .... but also realized that high reliability and high availability were primary requirements.So I put together a generic technical spec - generic in that it described the basic architectural building blocks of the site, but did not specify vendor specific part numbers or detailed configuration. The spec. also broke down the equipment into two procurement phases, which were called a Starter System Configuration and an Enhanced System Configuration. This would allow the site to go online with the starter config and, later, to be expanded to the enhanced config. Here is what the top level generic spec looked like:Starter System Configuration Overview Server Load Balancer (aka Application Switch) standalone appliance with: 12 * gigabit ethernet ports configured - 2 * optical ports to connect to the ISC infrastructure - 10 * copper UTP ports to connect to the web servers 2 * A/C power supplies Four 1U dual AMD Opteron based rackmount servers configured 2 * AMD Opteron 252 (2.6GHz) CPUs 8Gb RAM 2 * 146Gb U320 SCSI disk drives 2 * built-in copper gigabit ethernet ports 1 * dual-port gigabit ethernet expansion card Enhanced System Configuration Overview One Fibre Channel (FC) SAN disk subsystem configured 12 * 146Gb Fibre Channel 3.5" disk drives 2 * RAID Controllers with 1-GB Cache Each and battery backup 4 * 2Gb/Sec FC Host ports 2 * A/C power supplies Four Fibre Channel Host adapters PCI 64-bit low profile form factor 2Gb/Sec Optical LC connectors 2m Optical cable As you can tell, the reliability/availability comes from using a Server Load Balancer (SLB) aka Application Switch, to load balance incoming requests across multiple, backend, servers. The load balancer issues periodic health checks and, assuming all 4 servers are healthy, the requests will be distributed according to the selected load balancing algorithm to the available servers in the defined pool. The real beauty of this approach, is that you can also do scheduled maintenance on any of the servers by "telling" the SLB to take a particular server out of the available pool. You wait until all active sessions expire on the server, then disconnect it. Now you are free to ugrade or repair it. Lets assume you're upgrading the Operating System. After you've completed the upgrade, you have plenty of time to test exhaustively, because the other servers in the pool are serving your client requests. When you've satisified that the upgraded server is ready for production, simply tell the SLB to put it back into the pool. Your user community experiences no impact and are completely unaware that y[...]

How Genunix.Org got started (part 2 of 2)


OpenSolarisSolarisPeter LosherAl HopperBen RockwoodIt's 16 hours before the public launch of OpenSolaris as I write this paragraph and I'm getting really excited, but I'm also really tired. I've been working furiously to try to get a community run OpenSolaris site online in time to support launch. The actual hardware did'nt arrive at Logical Approach until late afternoon on Monday the 6th of June. The site hardware consists of 4 Sun V20Z servers in a maxxed out configuration - two 146 gigabyte drives, 8 gigabytes of memory and two AMD 252 (2.6GHz) Opteron processors. Three of the V20Zs and an N2120 Applications Switch (aka Server Load Balancer (SLB)) were sponsored by Sun, the 4th V20Z was contributed by our company, Logical Approach.Now if I did'nt have a day job at Logical - having this hardware arrive on Monday afternoon, with a scheduled install in an internet co-location facility 1,700 miles away on the Friday of the same week, would be doable. A push, yes, but doable. But, unfortunately we have our customers to look after and that week was pretty busy around here - aside from the ongoing Community Advisorary Board (CAB) activity and trying to keep up with the OpenSolaris Pilot program and mailing lists that were becoming increasingly noisey as we approached launch.We put off the planned Friday hardware install in Palo Alto, until Saturday, shipped out 3 of the machines for overnight delivery on Thursday and then shipped out the 4th V20Z and the Application Switch on Friday for Saturday (next day) AM delivery. You don't want to know what our FedEx bill looked like!But everything did'nt go smoothly. In fact we got stymied by the Application switch configuration process. Now, you may already know this; but Load Balancers, as a class of tech toys, are complex devices. That is just the nature of the beast. But, unfortunately, moving from one load balancer to another is like moving from one country to another foreign one; almost everything you learned previously is instantly obsoleted - including the language. The terminology changes completely. The menu system changes; the order of configuration setup steps change. In short, you may even feel that your previous experience (with Foundry Networks ServerIron and Alteon Websystems (now subsumed by Nortel)) seems more like a curse, than a blessing. Again, that's the nature of the beast.So I raised my hand for help (from Sun) on Friday around midday (Central Time). Yep .... that's a great time to ask for help! And finding the right person at Sun can be daunting, especially within such a large organization. It turns out that the N2120 Application switch is a product Sun acquired when they bought Nauticus Networks. It also happens, that the right person to help configure the switch was off getting married. How inconsiderate of him (just kidding)!So we shipped the switch in a state of less than digital nervana, overnight to Palo Alto and I was on the first flight on Saturday morning, departing from DFW (Dallas Fort-Worth) for San Francisco. The flight was great - the fun started after the plane landed. I had to check a roller-board type case, because it contained hand tools that would have been confiscated if I had tried to bring it onboard as carry-on baggage. It also contained a bunch of CAT-5 and CAT-6 ethernet cables - so it would very likely be given close scrutiny and hand checked.After the flight landed at SFO, it took about 40 minutes for that bag to make it to the baggage area! Now you know why everyone uses carry on baggage and all the storage space inside the cabin gets exhausted on most flights. Next up: Budget car rental. The first thing that was easy to see is that the entire car rental area at the airpot was mobbed out. I stood inline for about 30 minutes, got the paperwork done and then the lady helping me had an argument with someone responsible for getting cleaned cars ready for pickup in the nearby parking garage. She slams down the phone angrily. Another woman cuts across me and[...]

Linus must step aside


OpenSolarisSolarisHave you noticed that company founders or leaders often give up their pivotal role in a company that they have founded or been instrumental in leading? They either step aside or are forced out. Why is this? Because, in order for the company to continue to make progress and grow, they need to step aside. The smart ones recognize this - the dumb ones..... oh well.So lets examine this phenomenon. The people we are talking about usually share the following character traits: They are brilliant, very talented, visionary and very demanding to work for. These character traits are what makes them different and allows them to create a company or product that others are incapable of. Those are the upsides. But there are corresponding downsides.They are usually a royal pain in the ask to work with. Highly opinionated, very judgmental and apt to be very stubborn. They can also be inflexible. Again the smart ones recognize their weaknesses and surround themselves with other talented folk who help to balance out their personalities. It's not uncommon to find company partners with very different personalities and styles. And the dumb ones ... well no one can possibly be as smart or as talented as they are, and there's nothing wrong with their personalities anyway - so why even bother "playing well with others"!So here's my point: Linus Torvalds must step aside and let Linux flourish. Linux has reached the personal limitations of Linus - it's creator and mentor. It's currently limited by the mental boundries and personality of its founder. Oh and yes - it appears the Linus does not recognize this problem and does not understand, that he has to step aside.Lets take look at a serious limitation of Linux (the OS) which is a direct result of the limitations of Linus: Lack of a stable kernel API. According to Linus - having rigid APIs would limit the creativity of the kernel developers. Well ... yes it would, but it would also bring some decipline to the kernel code and it would allow a driver developer to deliver a device driver that does not have to be re-written every time the APIs change. It would also stop hundreds of developers from constantly rewriting and retesting their code every time the APIs change. It would also force the kernel developers to think with their minds and not with their keyboards!But is this doable? Can the kernel APIs remain stable and not stifle developer creativity? Answer: Yes and yes. Look at Solaris 10 and the DTrace facility. Over 40,000 tracepoints in the kernel with negligible impact on performance, and yet, the tens of thousands of lines of code that I've written, going back to Solaris 2.5 and earlier, still run on Solaris 10 without any changes! And the same code runs on SPARC and Solaris x86 - with just a simple recompile. Time is money - and just think of the dollars involved by not having to constantly rewrite and retest Solaris based code.On the flipside Linux has one thing going for it that Solaris does not have - a vibrant and active volunteer "army" of developers. But that's about to change when OpenSolaris goes live later this year. I'm a member of the OpenSolaris Pilot program and it's interesting and exciting to be perusing the crown jewels of Sun ... Solaris source code. Just think of it; you're looking at the fruits of the labors of hundreds of man years of effort from some of the most talented developers on the planet. Awesome.So step aside Linus - or be run over by the OpenSolaris juggernaut.[...]