Bill’s blog

I’m posting this because google is filled with unanswered questions and half-answers regarding this topic.

I’ve built Subversion 1.5.5 on a Solaris 10 sparc system using gcc. I had already set up a subversion server using the sunfreeware.com packages. However, I wanted to build my own self-contained subversion package to install on the other servers (”client-only” i guess, though there really is no such thing with subversion)

I was building this from source, because the subversion package on sunfreeware.com has too many dependencies and I was not interested in having to install all that extra stuff on every solaris box wishing to access my repository, especially packages like apache.

Step 1:
You will need to get the latest subversion source code. Make sure you get both the main package AND the dependencies package too!

Step 1b (optional):
If you require your subversion “clients” to talk to a subversion repository using ssl, you will need the Solaris openssl packages installed. Don’t try and build your own. I did, and later in this post you’ll see what happened. The Sun-supplied packages you will need to have installed on your system are:
SUNWopenssl-commands
SUNWopenssl-include
SUNWopenssl-libraries
SUNWopenssl-man
SUNWopensslr

Step 2:
Unpack the main package somewhere. Unpack the dependencies package on top of the main package.

I set the following environment variables:
LDFLAGS="-L /usr/local/lib -R /usr/local/lib -L /usr/sfw/lib -R /usr/sfw/lib -L /usr/lib -R /usr/lib"

LIBS="$LIBS -lintl"

Step 3:
Run the configure script. The configure options that worked for me in the end were:

--prefix=/opt/subversion
--with-ssl
--without-serf
--enable-shared="yes"
--enable-static="no"

Ignore any warnings it gives you about not finding BerkeleyDB. You don’t need it unless you are trying to access old repositories using that format. Any recent Subversion repositories are using the built-in fsfs format.

Step 4:
Run “make install” and you should be done!

Notes:

I ran into two problems which are extensively mentioned on subversion message boards. Here’s how I solved them:

1. Multiple inclusion of file errors while building neon libraries

/build/directory/.libs/libsvn_subr-1.so:
attempted multiple inclusion of file
Undefined first referenced
symbol in file
libintl_dgettext main.o (symbol belongs to implicit
dependency /usr/local/lib/libintl.so.8)
ld: fatal: Symbol referencing errors. No output written to .libs/svnadmin
collect2: ld returned 1 exit status

I fixed this by doing a two things:
- Make sure the $LIBS variable has “-lintl” included.
- Don’t build static libraries. I’m not sure why you would want to do this anyway. When running the top-level configure, include the options --enable-shared="yes" and --enable-static="no"

2. SSL disabled due to library version mismatch

When I was building this package, I wanted everything to be self-contained to reduce dependencies. So I downloaded openssl 0.9.8i and installed it in /opt/subversion prior to building subversion itself. However, no matter what I did, I was unable to stop getting this error, even when building neon separately and verifying via ldd that my binaries were all linking to the custom-built openssl libraries. I gave up and ended up just using the openssl 0.9.7 included in /usr/sfw/lib on Solaris 10. If you are like my workplace and install most of the OS packages on the servers, that library ought to be there, otherwise you will need to get your os media and install the packages manually. Once I set my LDFLAGS to include /usr/sfw/lib and rebuilt subversion, everything was ok. The neon-config script automatically includes /usr/sfw/lib, which I think is why most people are getting tripped up building subversion on Solaris 10. They may not install those packages with the OS.

Some guy in Finland posted a message to usenet about a project he was working on. The world has never been the same since.

http://www.linuxjournal.com/content/linux-turns-17

It was just over a year later, around November 1992 or so, when one of my classmates at Tulane, Larry Butler, told me of some unix variant that you could run on your pc. I was certainly intrigued.

At that time, I still had the 386sx/20 that I had bought just before starting college a year and a half before, it was getting rather old at this point, though I did upgrade it to a whopping 4 megabytes ram earlier in the year. I really only ever used it to call BBS’s, since I worked in the computer lab I could just use those computers for my schoolwork… they were newer, had all had the latest software, and were hooked up to laser printers which I got to use for free since I worked there.

So anyway, I decided to load this thing onto my computer. The only thing close to a pre-packaged distribution was something called SLS, which eventually grew into what Linux folks know as Slackware. You downloaded disk sets and loaded them onto 1.44MB floppy disks. The only pieces I had at first were the two main disks.. the boot disk and the root disk. I loaded it up and was just blown away by the fact that I had a unix login prompt showing on my computer.

The next thing I did was get some more of the disksets and find some terminal software so I could call BBSs. Minicom proved to be a easy substitute to the Telix that I had been using in DOS. Yep, all text mode for me.

It was from then that I decided to ditch DOS and run this Linux full-time as my computer OS. My requirements were minimal, so this did the job, and hey it was unix, how cool was that.

For the rest of my sophomore year and through junior year I got a reputation on campus among my fellow computer geeks for being the Linux Guy(tm) which helped me get a job during senior year as the system administrator for the biomedical engineering department, where I managed servers running several different flavors of unix, including OSF/1 running on a DEC Alpha and UNICOS on a smallish Cray machine (by small, I mean it was about half the size of a refrigerator)

That on-campus experience was sufficent to get me a real system administrator job up in the Chicago area after graduation.

13 years and 5 companies later, I don’t know what else I’d want to do.

Requirement #1: Standard Partitioning Scheme For All Servers

Setting up a jumpstart profile with a standard partitioning scheme is very trivial, when you have a small number of servers or all your servers have identical hardware. But this requirement presented me with a challenge. I support around 15-20 different models of Sun and Fujitsu (Sun clone) servers running Solaris 8, 9 and 10. The only thing they share in common is that every one of our Solaris servers, no matter its purpose, contains two internal disks of the same size, either 36, 73 or 147GB so that they may be mirrored together for redundancy. Some servers may even contain additional internal disks. Because of this, I wrote a Begin script that automatically generates a profile based upon the OS version and hardware detected. The Sun documentation calls these generated profiles derived profiles.

Because of the variety of hardware I support, there are many things to consider:

1. The root disk is not always c0t0d0.

Jumpstart will always select the rootdisk by picking the first disk to show up in a probe… c0t0d0 in this case. Thankfully I have never run into an instance where an alphanumeric sort of all detected cXtXdX devices did not show the correct rootdevice as first in the list.

2. On a system where you have more than two internal disks, which is the secondary (mirror) disk?

Consider this real-world example from one of my servers:

c0t0d0 - 73GB
c0t1d0 - 147GB
c1t0d0 - 73GB
c1t1d0 - 147GB

Which is the secondary disk, the one you want to mirror to? Jumpstart doesn’t know or care. To you and me, its obviously going to be c1t0d0. However, if all four of these devices were the same size, which would make the best choice of a mirror disk? Most people would agree that mirroring across controllers makes the most sense, so it’d still be c1t0d0.

The ability to configure disksuite (SVM) mirroring of the root disk in a jumpstart profile was introduced in Solaris 9. Prior to that the only way you could mirror the disks during the system build was with a script you would put at /etc/rc2.d/S99firstboot (or some such name) that ran the disksuite commands, updated vfstab and rebooted the system on the first boot. This works fine, but you still need to figure out which disk to mirror to.

The begin script takes care of this issue. It takes an inventory of all drives detected by the kernel via the ${SI_DISKLIST} and ${SI_DISKSIZES} variables.

The following order of logic is used to select a mirror disk:

• Is there only one disk of the same size besides the rootdevice? If so, select it.
• If there are multiple disks matching the size of the selected root device, do any of them have the same target number but different controller number? If so, that’s what we want.
• If there are multiple disks matching the size of the selected root device, but all the ones on other controllers have differing target numbers, pick the first one found on another controller.
• If the only disks matching the size of the root device are on the same controller as the root device, pick the first one from that same controller.

Note About Configuring Disk Mirroring via Profile vs Mirroring At First Boot:

With Solaris 8 builds, we have no choice but to partition the root disk and install the OS to it, saving the mirroring step until the first boot of the new system. With Solaris 9 and 10, we can set up the disk mirroring in the profile itself.

However, with Solaris 9, I have found that configuring mirroring at profile time rather than at first boot gives us a significant performance penalty when installing the OS. Installing Solaris 9 with all updated patches takes 4 hours when disk mirroring is configured in the profile. It takes only two hours when the mirroring is done at first boot. Solaris 10 is lightning fast (in comparison) with mirroring configured in the profile, so I have not had to try and get it to set up mirroring on first boot.

3. Which packages do you install?

Different versions of the OS contain different package cluster names, etc. Depending on the contents of the variable ${SI_OSNAME}, we write the appropriate package cluster list to the derived profile.

With all these items addressed, we can write out the profile!

Sample generated profile for Solaris 9:


install_type initial_install
system_type standalone
locale C
partitioning explicit
isa_bits 64
cluster SUNWCXall
<additional cluster/package add/remove commands here>
filesys mirror:d0 c0t0d0s0 c0t1d0s0 15120 / logging
filesys mirror:d10 c0t0d0s1 c0t1d0s1 10240 swap
filesys c0t0d0s2 all overlap
filesys mirror:d30 c0t0d0s3 c0t1d0s3 10240 /opt logging
filesys mirror:d40 c0t0d0s4 c0t1d0s4 10240 /var logging
filesys c0t0d0s5 free
filesys c0t1d0s5 free
metadb c0t0d0s7
metadb c0t1d0s7


I’ve spent the last several months working on a solution to do Solaris OS installs, upgrades and bare-metal restores. Of course, in the Solaris world, automated installs typically means “jumpstart”.

Yes, there are add-on packages to allow you to do more things easier with Jumpstart such as JASS and JET, and likely more that I have not mentioned.

When I decided to take on the issue of doing system builds, I inherited a partly-done setup a contractor had put together with an older version of JASS installed, so I just ran with that.

My requirements were:

1. Standard partitioning scheme for all servers
2. All servers followed the company security standards 100% from the initial build with no admin intervention.
3. Third-party software installed and configured without admin intervention.

The following posts will show how I deal with these issues for initial installs.