Category Archives: opensolaris
Sun Glassfish Webstack 1.5
Sun Glassfish Web Stack 1.5 is out this week, for Solaris and Linux platforms.
This is the latest update to the webstack, and like previous versions is available both as a free download and commercially as a supported product in a choice of bundles, to meet the needs of everyone from enterprise clients, through small and medium size business and startups, to students and hobbyists. The most striking change for most users will probably be the shiny new Enterprise Manager dashboard.
Open sourcers will note the updates to the constituent open-source components of the webstack. In this context, and in view of my recent blog entry, I should perhaps mention that while the Apache HTTPD version bundled is 2.2.11, it does include local patches, most importantly the security fixes in this week’s 2.2.12 release from Apache. Other components are similarly upgraded.
OpenSolaris at the top!
Brazil’s OpenSolaris community seems to number President Lula da Silva himself among its supporters, as evidenced by Ludo’s photos.
I guess that’s setting a new challenge for any software community to equal, let alone beat! Will someone get Obama?
OpenSolaris 2009.06
A week late[1], I’ve got around to installing OpenSolaris 2009.06. For the first time with OpenSolaris, I ran it purely as an upgrade on the existing install (2008.11). It seems to have gone smoothly, and the only bad thing I’ve discovered is that it’s installed Firefox 3.1, which breaks a couple of my plugins. Just get me a working hibernate, and it’ll be ready to become my regular, full-time desktop box!
[1] A week ago it was too hot to think about this, and the OpenSolaris box appeared to be suffering from the heat too.
mod_privileges for Apache 2.2
I committed mod_privileges to Apache HTTPD trunk late last year, so it’s available to users of trunk. Since we have yet to release an alpha 2.3 (let alone a beta or stable 2.4) version, that’s a limited audience.
I’ve now hacked up a simple patch to enable it to be run with Apache 2.2 (prefork MPM). You can safely apply the patch whether or not you use mod_privileges, and I’ve proposed it for backport so it may become standard in future 2.2 releases. The module itself will remain separate, but may be bundled in future releases of Sun’s webstack.
Links:
OpenSolaris 2008.11
This is my first post from OpenSolaris 2008.11.
First impressions: I like it. A smoother, easier experience than 2008.05, and more up-to-date goodies than SXCE. But I expect I may have a gremlin or two yet to come: time will tell.
I have SXCE still on the other half of my hard disc in the Sun box. Using old-fashioned partitions is probably a mistake, but it gives me clean dual-boot – or will do, once I’ve figured out the Grub magic. Grub documentation tends to be Linux-oriented, so I have to figure out the Solaris equivalents for device and kernel names. Even on Linux (and multi-boot systems) I’ve always used LILO in the past.
That installer is for the most part very smooth and easy: the only questions I had to answer concerned my language, keyboard layout, and timezone, and setting up an account and passwords. But in one glaring respect it’s still a royal pain: there’s no decent fdisk facility, and it’ll wipe any existing Solaris partitions you have (that’s actually why I’ve put off installing it so long). Oh, and it doesn’t offer any control over installing the bootloader (Grub). Before installing 2008.11, I had to mark the SXCE partition as Linux in the partition table (that makes no difference to the data on the partition, but just tells the OpenSolaris installer to leave it alone). Actually I guess anything non-Solaris would’ve sufficed, and maybe the installer would’ve set up dual-boot for me if I’d marked it as NTFS ….
Anyway, if all goes well I’ll look forward to migrating my day-to-day work to this platform.
Separating Virtual Hosts: mod_privileges
A longstanding issue with web hosting on Apache is the problem of lack of separation of virtual hosts. Users of a system had better trust each other, because if they have privilege to deploy non-trivial applications, they’re likely also to have privilege to crack each other’s apps. Of course the level of vulnerability depends on local factors – mostly the competence of the sysop – but it’s always a worry for security-minded users.
A complete solution to this is full virtualisation, including an entire apache instance per user. But that’s expensive. A range of partial solutions exist: generally these involve separate processes such as suexec and fastcgi (both for CGI). The perchild MPM promised full privilege separation, but was abandoned.
I have today uploaded a new module mod_privileges to Apache svn, under modules/arch/unix. This is a module for Solaris 10 and OpenSolaris, that uses Solaris privileges to enhance webserver security. Specifically, it enables both privileges and Unix user&group to be specified per virtual host. Like the perchild MPM, each virtual host can run as a different system user, and it will also (by default) run in a more secure mode than “normal”, by removing privileges rarely used by a webserver. A BIG_SECURITY_HOLE compile-time option lets you shoot yourself in the foot by running with your choice of privileges.
mod_privileges is currently in /trunk/, and won’t be in any released version of Apache for a while. It will require further work – including of course security audit – before it can be recommended for operational use.
And it has a major limitation: it won’t run with a threaded MPM. But neither will mod_php (at least not in a sane setup), so PHP users have nothing to lose. It’s also useful for other in-process scripting environments such as mod_perl, mod_python or mod_ruby. And therein lies its major target market: hosting companies offering scripting should find this meets a long-standing need!
Beware bfu and other gotchas!
More grief with OpenSolaris.
My SXCE seemed a decent, stable desktop platform. Until, that is, I installed crossbow – experimental support for advanced networking, including a complete virtual network within a box.
Crossbow installation went according to the instructions. I think a message or two flashed past, but basically it’s what TFM had led me to expect. On next boot I got quite a few more warnings, but I think that’s at least in part because I’d upped the verbosity and was seeing debug stuff that wouldn’t otherwise hit dmesg.
The network-inna-box worked. But various other things had gone. Strangely, punchin VPN still worked, but it had uninstalled my certificate – not hard to fix once I’d run it outside the GUI and got the error message. And I could live with trivialities like the loss of a system alert beep. But then I found some of my most-used tools broken: gdb just segfaults, and svn failed with an incomprehensible error message (reinstalling svn from source gave a different message). Looks like incompatible core system libs somewhere, and google finds nothing relevant. Ouch!
Chatting to Matt on IRC, it seems the culprit was the installer, bfu. bfu creates a binary install image tied to an exact system release. On a later release, as I had been using, it installs but leaves the system in an indeterminate state. Bah!
Last weekend I backed up the home directory, and reinstalled. Not just reinstalled, but spent many hours downloading updated versions: the latest SFW tarball took the longest, at less than 20K/sec download rate – compared to over 200K for most downloads. And I reinstalled a lot of system software.
One upgrade was Sun Studio 12. The installer told me I had insufficient disc space(!) – seems the system install had put /opt on the root partition, and it wasn’t big enough. So I tried an alternative install path, and it installed. OK, fine.
Then my big mistake. After some build tools had failed to find it, I tried creating a symlink. Guess I must’ve used “ln -s /my/install/path/SUNWspro /opt/SUNWspro” but there was already an /opt/SUNWspro (dunno whence), so the symlink was – uselessly – at /opt/SUNWspro/SUNWspro. OK, need to move the directory before I can add the right symlink: something like
cd /opt
mv SUNWspro SUNWspro-bak
mv SUNWspro-bak/SUNWspro .
At this point, something very strange happened. Instead of moving the symlink, it started copying. Looking like one of those modern mv versions that uses cp and rm when asked to move across partitions. Except – I’d only asked it to move a few bytes of symlink, and only within one partition, hadn’t I? df confirms that something is going on, and I abort the mv before it’s filled the root partition.
Now I have a system where I can neither uninstall nor reinstall sunstudio. The uninstaller is a dangling symlink, and the installer complains of a partial installation. Well, actually it just reports failure, but trying it in another directory just gives me “Installation directory does not match directory of current partial installation“. Googling the exact error message gets me this page, which looks almost like it could be relevant. pkginfo -p shows nothing, and the prodreg tool shows me a damaged sunstudio installation, but throws a java exception when I try uninstall (it’s the dangling symlink – turns out prodreg’s uninstall is just a wrapper for that). pkgrm also fails with a “no package associated with <SPROsslnk> ” message.
Right. Time to cut my losses, and reinstall again from that DVD, and override its default partition sizes this time. But at least I can skip the big downloads this time Backed up the newly-downloaded stuff even as I blogged …
[update] I may have been on the point of giving up too soon. The prodreg tool has a lower-level option than using the package-supplied uninstaller (the broken symlink). That seemed to uninstall, whereupon reinstalling once again tells me it failed, but leaves me an installation that prodreg thinks is OK, and that seems (so far) to work …
Yay for Zones!
Well, I’ve still no idea what killed my SFW build.
But after further attempts to fix or work around it, I’ve gone for an alternative approach. Instead of just running it as its own user (as I started out doing), I’ve created a new Solaris Zone dedicated to sfw. And of course an sfw user within that zone. I’m happy to say that it works within the zone, so I’m back on track and (hopefully) isolated from whatever caused the trouble. Evidently zones have more to offer than mere security 🙂
Next, I’m playing about with creating a virtual network amongst zones. Slightly confuzzled by the significant differences between my solaris version and the crossbow docs (such as Sunay’s blog) in, for example, the dladm command, but I think I can work around that.
Confuzzled
Still (evidently) not got to grips with the SFW consolidation.
Having successfully executed a full build with one additional module, I thought I was past the steep bit of the learning curve, and added in six more modules. Of course I didn’t expect them all to build successfully first time – bound to hit snags, typos, gotchas, miscellaneous bugs. But I did expect to get meaningful error messages from those modules that failed to build.
It didn’t build. httpd itself failed, so the modules didn’t even have the prerequisites to try to build. The error was an invalid –with-apr in the configure. Seems that it tries to build both prefork and worker MPMs, but with just one APR build (on worker). That relies on worker getting built before prefork, and the error suggests that didn’t happen.
Having failed to figure out what among my changes could possibly have caused this (unexpected) error, I fell back to recreating the entire hierarchy from the same clean tarball I’d started out with. Same error! So it wasn’t anything I’d done, and looks suspiciously like a heisenbug. Bugrthat 😦
OK, I wonder what happens if I just remove those –with-apr configure options from the apache-prefork build? Hopefully it’ll get though to building the modules, so I can get the results I want: successful build or relevant errors! It’s running now.
SFW
Continuing my epic Adventures in OpenSolaris, I was able to burn a DVD of SXCE.
I’m happy to report that since then I’ve installed SXCE, and things are going much more smoothly under it. OpenSolaris (2008.05) is for the time being relegated to a VirtualBox, where its quirks are pretty much harmless. SXCE seems to be a much more stable platform to work on.
That also means I can now build the SFW (Sun Freeware) consolidation, and thus work within Sun’s development environment. Which was basically the goal of the exercise. I’ve navigated my way around it just enough to integrate one of my own Apache modules, which now successfully builds and generates a package.
This is still not an environment I’d choose to work in: the SFW consolidation is huge and unwieldy, and its build is an epic several-hour job. I need to figure out at least how to sync my work with the repository rather than use giant tarballs. But at least I’m now able to do Sun work in its primary target environment of Sun’s webstack (which is part of SFW).
niq's soapbox 
