Sunday May 04, 2008

2008.05: More ways to get it

As I did for the preview releases, I'll collect links to mirror sites here. These will also get links on the various download pages out there.

Bart and I just finished updating the package repository with the new packages we'd received the past few weeks, and that means 2008.05 is out the door. (Thanks to everybody who tried the release candidate, filed a bug, shuffled a package, wrote or proofread a document, or just spent energy anticipating the bits.) You can get the ISO image, suitable for burning to a 700 MiB CD or immediate use in virtual environment, directly from the following locations:

Reading the logs, and talking with some of our mirror sites, we know we all served out a lot of downloads for the previews; if you're interested in being a mirror, please let me know. (2008.05 remains completely redistributable.) We're using a bigger download complex this time, but every mirror helps.

If you already downloaded and installed Preview 2, it's more complete, easier, and probably faster to update directly using image packaging: see the update guidelines. These instructions involve a small script to safely update a clone of your installed system, and then switch to that on a system reboot. (If you were running Preview 1, you should update that to Preview 2, and then go on to 2008.05.)

Update 1: My thanks to Tobias Lundquist, who's once again mirrored via FTP and HTTP (Internet 2) in Sweden.

Update 2: My thanks to Luca, who's put up an HTTP mirror in Romania.

Update 3: Simon Valiquette has put up an HTTP mirror (Internet 2) at the Université de Sherbrooke in Québec, Canada. Merci, Simon.

Update 4: Bart Muijzer has arranged for mirrors by the Netherlands Unix Users Group (NLUUG) and surfnet.nl. Thanks, Bart.

These links are for the gzipped CD image, which contains the 12 "primary languages". It installs quite a bit faster, particularly on systems with slower CPUs. There is also an LZMA-compressed image, which has localization support for 42 languages, including those primary ones. It's available from dlc.sun.com, genunix.org, ftp.df.lth.se, mirrors.xservers.ro, and as a torrent. (Consult the language lists for specifics.)

[ T: ]

Thursday Feb 21, 2008

pkg(5): Reverse proxying your depot with Apache HTTPD

As part of the changes to get Developer Preview 2 ready, we decided to rejigger the HTTP handling on pkg.opensolaris.org so that we could have more options as more people attempt to use the early versions of image packaging. Previously, we ran pkg.depotd directly on port 80, in its read-only mode; now we use Apache HTTPD to listen on port 80, and use mod_proxy to proxy those incoming requests to a pkg.depotd instance listening on a separate port. With a couple of different approaches

Proxying and rewriting is one of those endlessly fun activities that somehow actually ends up being productive. Last time, proxying fun led Steve and I to fiddling around such that we ended up with proxy and rewrite patterns to enable the country portals for opensolaris.org.

If you want to share the top-level component of your URL space, you'll need to watch pkg(5) developments, as you have to map the list of operations one-by-one—and I know there are some new operations forthcoming. That would involve adding something like the following to a VirtualHost directive in your Apache configuration.

ProxyRequests On

Redirect /index.html http://pkg.opensolaris.org/status

ProxyPass /abandon http://pkg.opensolaris.org:10000/abandon
ProxyPass /add http://pkg.opensolaris.org:10000/add
ProxyPass /catalog http://pkg.opensolaris.org:10000/catalog
ProxyPass /close http://pkg.opensolaris.org:10000/close
ProxyPass /feed http://pkg.opensolaris.org:10000/feed
ProxyPass /file http://pkg.opensolaris.org:10000/file
ProxyPass /filelist http://pkg.opensolaris.org:10000/filelist
ProxyPass /manifest http://pkg.opensolaris.org:10000/manifest
ProxyPass /open http://pkg.opensolaris.org:10000/open
ProxyPass /search http://pkg.opensolaris.org:10000/search
ProxyPass /versions http://pkg.opensolaris.org:10000/versions

ProxyPass /css http://pkg.opensolaris.org:10000/css
ProxyPass /logo http://pkg.opensolaris.org:10000/logo
ProxyPass /icon http://pkg.opensolaris.org:10000/icon

ProxyPass /status http://pkg.opensolaris.org:10000/

Configuring your server in this fashion allows you to mix an image packaging server in with your other site content. You can easily deliver static content alongside your depot, for example.

If you don't mind pushing your package repository down one level in your URL space, then the above simplifies to

ProxyRequests On

ProxyPass /pkg/ http://pkg.opensolaris.org:10000/

(which should be a hint on how to create a repository farm under a single URL). To use the latter, you would use pkg(1)'s image-create subcommand

$ pkg image-create -F -a mypkgs.com=http://www.myserver.com/pkg /path/to/image

to connect your image to your reverse-proxied packaging depot.

In the two examples above, you should of course replace machine names like pkg.opensolaris.org and port numbers like 10000 with values appropriate to your own installation.

Happy proxied package serving!

Feel free to share your alternative configurations or approaches with other HTTP servers here, or on pkg-discuss-AT-opensolaris.org.

[ T: ]

Tuesday Feb 12, 2008

Indiana: More ways to get to Preview 2

As I did for Preview 1, I'll collect links to mirror sites here, as well as on the project page.

So we just released the second Indiana preview ISO, which you can get from the following locations:

We had a lot of downloads for Preview 1; if you're interested in being a mirror, please let me know. (Indiana remains completely redistributable.) We're using a bigger download complex this time, but every mirror helps.

If you already downloaded and installed Preview 1, it's more complete, easier, and probably faster to update directly using image packaging: see the update guidelines on opensolaris.org. These instructions use ZFS and pkg(5) to safely update a clone of your installed system, and then switch to that on a system reboot.

Update 1: My thanks to Tobias Lundquist, who's once again mirrored via FTP (Internet 2) in Sweden.

Update 2: My thanks to trisk, who's once again put up an HTTP mirror (Internet 2) on the East Coast of the USA.

[ T: ]

Monday Nov 05, 2007

pkg(5): Fueling the next steps

Most Fridays, I spend the two hours before lunch assisting at our co-operative daycare. The hour and a half before are pretty good thinking hours, most of which lately have been spent on packaging. As the year passes, and we move into fall here in Northern California, the thinking's been best assisted by having a brief, and warming, snack.

Still life with packaging

The notes being written are about some of the points raised about the use of hashing, but then I buckled down and wrote an outline for our ARC inception materials, which will probably take more than one or two Friday sessions.

Location: Café Borrone, Menlo Park, California.

[ T: ]

Friday Nov 02, 2007

Indiana: More ways to get it

So there are a few ways to get a copy of the Indiana preview ISO:

Both our mirrors are in Northern California, so—since it's a completely redistributable set of software—if you're interested in being a mirror (even in California), please let me know. If you're a torrent fan, come join me and seed.

Update 1: My thanks to trisk, who's put up a fast mirror (Internet 2) on the East Coast of the USA.

Update 2: My thanks to Tobias Lundquist, who's put up an FTP mirror (Internet 2) in Sweden.

Icon Design by IconBuffet (from "Durango Office" and "Durango Research").

[ T: ]

Wednesday Oct 31, 2007

Indiana: VESA if you need it

Over the past week, as we kept reassembling the distro constructor, image packaging, and slim install, we tested installs on a bunch of laptops. This manual operation let me rehearse how to get things working if the Preview LiveCD doesn't have a graphics driver that will work. So: here's the VESA workaround.

  1. Boot text mode. One of the non-default lines in the GRUB menu should say "text"—pick that one.
  2. Login as jack. User is "jack", password is "jack".
  3. Generate a representative xorg.conf. Become root and have Xorg generate an initial configuration. The root password is "opensolaris". (Enjoy that `root`'s default shell is 'bash' for a bit.)
    $ su
    Password:
    # /usr/X11/bin/Xorg -configure
    ...
    
    This procedure should create /jack/xorg.conf.new.
  4. Change the driver. As root, you'll continue by editing that xorg.conf.new file in vi(1). Search for the Device section, and modify the Driver line to
        Driver  "vesa"
    
  5. Make it go. Stay root and hand-launch GNOME.
    # /usr/X11/bin/xinit /usr/bin/dbus-launch gnome-session -- \\
            /usr/X11/bin/Xorg -config /jack/xorg.conf.new :0
    
  6. Launch the installer. Bring up a terminal, and invoke the installer, by typing install-lan &.

If your install fails, please file a bug report at defect.opensolaris.org. If it succeeds, but graphics doesn't work, you can follow the same steps, but you'll have to edit the GRUB entry. (Roughly, type 'e', add "-s" to the end of the line with kernel/unix, and log in with the new root password you set during install. I haven't tested this portion—let me know if it fails.)

Last night, I had to do this for my trusty VAIO T370P, but tonight it's fine:

Developer
Preview

Please let us know how it goes.

[ T: ]

Friday Aug 24, 2007

pkg(5): Leaving the build system "out"

I've been busy the past weeks with school transitions and with getting the community defect tracking system requirements into a shape where we can start evaluating candidates.

Identifying the boundaries of a system during the design phase affects feasibility critically, perhaps more than any other choice. This choice reduces to "know what you're trying to create". As with my previous post, I'm going to describe something we're not doing—and explain why. I envision one more negative post, and then we'll get onto more positive expressions.

So: this packaging system does not contain a build or compilation component in its core architecture. There are pragmatic reasons for this choice, as well as technical ones.

One way to look at a packaging system is, similar to how we saw it as the connecting layer between the installer and lower-level OS services, as a way to collect and organize the set of components, binary and otherwise, into an always "bootable" flow of change. That is, various groups of people are, using their systems, emitting binaries, documents, images, and so on, that other groups of people combine into releases (or atoms of a release, like an updated package). The packaging system has to assist the latter group in that combination, by providing visibility into the completeness of the outputs of the former groups. It's less clear that the latter group needs to have the ability to construct the objects, as long as they can assess that the environment the objects need to execute can be realized.

Just as an aside, we're treating as critical design input exactly who touches and how they touch a software component as it proceeds through development, localization, release engineering, sustaining, and so forth. These touches might be reduced as the development becomes more open, but at present, they're a useful constraint on any tendency to make the system overly rigid (or overly monolithic).

The OpenSolaris consolidations—and related open source outputs like OpenJDK or OpenOffice, among others—don't presently share a common build system. In fact, one of the real impacts of Sun's progression to an open software development culture is that we're moving from being the originator or primary maintainer of 90% of the software we deliver, to a much more modest percentage—let's say 30 – 50%. Forcing a unified build system upon all of these disparate products is asserting the need for a long series of difficult conversations over many months.

Instead, let's defer those discussions, and see if we can get the same benefits while only managing the end outputs of each of the participating (or aggregated) publishers. (A byproduct is that injecting received binaries into the system is the common case, rather than a strange or special workaround.) As we noted in the earlier post, we have goals about safety, developer burden, and stopping "bad stuff" as early as possible.

Static analysis can get most of the dependency cases correct. Binaries, whether they are user applications, libraries, or kernel modules, contain a significant amount of dependency information. It turns out that many scripting languages can be roughly interpreted to determine their module requirements. Similarly, Java class files and JAR files—and even smf(5) manifests—contain a great deal of information that lets us determine the self-consistency of a system.

Of course, a program can evade these dependencies: beyond use of dlopen(3C), it can implement its own linking or overlay mechanism, or simply be implemented in a language unknown to the packaging system. The point is we can drive out most of the inconsistencies that a purely manual dependency statement allows. In fact, we can warn a developer about the incompleteness of their dependency statements, potentially correcting them: adjusting version requests, inserting omissions, even asking about possibly superfluous dependency correctness.

That said, it might be that an ideal build system is lurking out there to be layered atop this system; we'll leave room for expressions, like stating a build dependency on a certain tool, like lex(1) and yacc(1), say, so that a build system (or systems, if folks can't close those difficult conversations I mentioned) can benefit from the metadata discovered about each component. (If you're interested in constructing such a system, we thought a little about requirements for the SFW consolidation.)

[ T: ]

About

sch

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
External blogs