unixzone dot dk

Oracle has done it, without a paid support contract you cannot get ANY Sun patches, not even critical security patches. http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1.

I don’t believe this is the correct way to do business, sure they stand to make a bit more money but in the grand scheme of things I can’t see it making much of a difference, only thing that will happen is that a lot of current customers will get pissed off with the new policy, and new potential customers will go a non-Sun/Oracle route ie. Linux or Windows (MS still supply free security patches).

Here is an OpenSolaris thread on the subject.

For more than 27 years, Sun has led the way in network computing innovation. And while oftentimes taking the road less traveled, our journey has delivered some of the most revolutionary — and evolutionary — ideas, business practices, and products. From Solaris to Java, open standards to open source, high-performance computing to eco computing, and everything in between, we’ve created a vibrant culture and a rich history, both of which we’ve shared with our partners, developers, students, universities, and of course, our customers.

We asked Sun employees from around the world to share some of their favorite anecdotes about their experiences at Sun. Take a look back at some of our more memorable moments and celebrate the unique culture that is Sun.

This is a great site with lots of history about Sun Microsystems, how Sun made a difference to it’s employees and the world, it’s innovations throughout the years, jokes, pranks, t-shirts and all the things that made Sun special, go check it out!

http://www.thenetworkisthecomputer.com/
 

This may not come as a surprise to many of you, especially the ones who have used OpenSolaris for a long time, but for myself who have only recently started tampering with the Indiana branch of OpenSolaris it took a few minutes to figure out what was going on.

When running Apache’s configure on OpenSolaris build 131 it would bomb out at:

Configuring Apache Portable Runtime Utility library...
checking for APR-util... yes
adding "-L/usr/lib" to LDFLAGS
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: in `/root/httpd-2.2.13':

Checking config.log showed me that it failed at cc1: error: invalid option 't' Odd!
It didn’t immediately occur to me that it was using the OpenSolaris supplied APR-util which is using the SunPro compiler.

So, the solution is to run configure with the --with-included-apr option.

Yesterday the OpenSolaris Install team released their first preliminary version of OpenSolaris which is capable of installing without a GUI, meaning entirely text based, this is great news and in due time now that SXCE is being pulled. It should now be much easier to install SPARC and xVM DomU’s, and what’s equally exciting is that it doesn’t install GNOME, this is ideal for servers where you don’t want all that GUI clutter.

The install team has been working on a text-based installer for OpenSolaris.
While this installer is not quite complete, given the timing of the SXCE to
OpenSolaris transition, we are making available a preliminary version of the
text installer, based on OpenSolaris build 131:

o supports SPARC/x86
o 512 MB minimum memory requirement
o cpio based install
o installs basic headless server environment (no Gnome Desktop)
o tip/serial line install recommended for SPARC

These are pre-integration bits from the project gate. Updates will be provided
with each successive build of OpenSolaris until such time as a formal delivery
is complete (after 2010.03) and RE assumes the building and distribution of images.

The CD images are located at:
SPARC:
http://dlc.sun.com/osol/install/downloads/text_install/131/textinstall-131-sparc.iso
Size: 674 MB

x86:
http://dlc.sun.com/osol/install/downloads/text_install/131/textinstall-131-x86.iso
Size: 680 MB
http://dlc.sun.com/osol/install/downloads/text_install/131/textinstall-131-x86.usb
Size: 816 MB

MD5 sums are located at:
http://dlc.sun.com/osol/install/downloads/text_install/131/md5sum.txt

Please read the release notes page at:
http://hub.opensolaris.org/bin/view/Project+caiman/Text+Install+b131+Notes
for known limitations, a FAQ, and a link to open bugs.

Bugs can be filed on bugzilla at http://defect.opensolaris.org
Classification: Development
Product: installer
Component: textui

For more information on the text installer, see:

http://hub.opensolaris.org/bin/view/Project+caiman/TextInstallerProject

Please refer any questions to: caiman-discuss@opensolaris.org

Thanks,
Sue

Sun’s own DHCP daemon is not often used for anything besides Jumpstart/PXE boot and SunRay’s presumably because it’s not as well documented and accepted as the ISC DHCP daemon. I recently had a need to quickly setup a DHCP server and serve out a range of IP adresses including DNS servers and a default router, all in all very basic. Here are my notes.

Setup DHCP in /var/dhcp using the SUNWfiles format
# dhcpconfig -D -r SUNWfiles -p /var/dhcp

We only want to serve DHCP requests on bge1
# /usr/sbin/dhcpconfig -P INTERFACES=bge1

Add new network
# dhcpconfig -N 172.22.2.0 -m 255.255.255.0 -t 172.22.2.1

Display dhcptab table
# dhtadm -P

Modify network/macro with various options
# dhtadm -M -m 172.22.2.0 -d ':Subnet=255.255.255.0:Router=172.22.2.1:Broadcst=172.22.2.255:DNSserv=8.8.8.8 8.8.4.4:LeaseTim=86400:' -g

Add one client IP
# pntadm -A 172.22.2.101 -c dhcp101 -m 172.22.2.0 172.22.2.0

Adding several client IPs
# for IP in 102 103 104 105 106 107 108 109 110
do
pntadm -A 172.22.2.${IP} -c dhcp${IP} -m 172.22.2.0 172.22.2.0
done

Delete client IP
# pntadm -D 172.22.2.107 172.22.2.0

Display DHCP network table
# pntadm -P 172.22.2.0

Documentation: Solaris System Administration Guide: IP Services > DHCP

Allan Coopersmitch has posted a short explanation of what is going on now that SXCE (Solaris Express Community Edition) will no longer be available past january 2010.

There’s been some confusion over the upcoming changes as SXCE ends while
Nevada builds continue to be published to the IPS package repositories,
so this is an attempt to clear up some of that.   (Just in case it’s unclear,
I am writing this is as an engineer trying to explain our work – I am not any
sort of official spokesman, nor am I announcing any policy changes.)

What’s changing at build 131:

- The OS install images will only be available in IPS packaged formats.
This means installs will be done via LiveCD (x86) or Automated
Installer (SPARC or x86) – the old Install DVD, network install,
jumpstart, and live upgrade all rely on the SXCE/SVR4 packaged
images,    which will not be available after build 130.

Most consolidations provide the same packages via both mechanisms,
though the IPS versions have some changes, such as merging the
split / (root) and /usr filesystem packages into one combined package.

A number of packages that were already scheduled for removal from the
next release of Solaris, or which are not redistributable due to third
party license encumbrances, are not included in the IPS repositories.

For instance, for X, we’ve not packaged Xsun or the legacy SPARC graphics
drivers in IPS format, so once this changeover is done, SPARC
platforms will only have Xorg, and only have the graphics drivers for
astfb (AST2000, 2100), efb (XVR-50, 100, 300), and kfb (XVR-2500).

CDE has similarly only had IPS conversions done of the packages for
the non-EOF portions (Motif, Tooltalk, dtksh, etc.) and most of the
CDE desktop applications & environment will go away in the transition.

What’s not changing at build 131:

- Build schedules – still every two weeks (except at holidays), still
following the same Nevada build schedule and build sequence – the
builds continue to be numbered “snv_131″, “snv_132″, etc.

See http://hub.opensolaris.org/bin/view/Community+Group+on/schedule
for the ongoing schedules for when the code freezes occur and the
packages are delivered to the release engineers who build the ISO
images and IPS repositories.   As before, these are *build* schedules,
not release schedules, and release of the built product remains about
two weeks behind the build date shown.

- Bug tracking – the release is still “solaris_nevada”, and the builds
have the same names as before.   Developers won’t start ignoring
all “nevada” bugs, but once the changeover happens bugs that only
affect the SVR4 install methods (live upgrade, pkghistory, postinstall
scripts, etc.) may be either marked with the “no-snv+” keyword
to indicate they are not Nevada bugs if they affect prior releases
of Solaris, or closed as will-not-fix if they only applied to the
Nevada versions.

Bugs for most of the OS should still be filed into Sun’s bugster
database via the http://bugs.opensolaris.org/ website, though
IPS, OpenSolaris Installation, and Desktop bugs should continue to
be filed in the bugzilla database at http://defect.opensolaris.org/

- Code repositories – the Nevada gates/repositories for all the
consolidations will still be used – onnv for ON, XW_NV for X,
sfwnv for SFW, etc.

- The packages created by building the code – for the next few builds,
all consolidations will continue to generate SVR4 packages for their
builds, and the IPS team will continue to convert them to IPS, just
as they have been since the IPS builds started for the first
OpenSolaris release.

ON will be changing generate IPS packages first, after the 2010.03
release of OpenSolaris, as noted in:

http://mail.opensolaris.org/pipermail/on-discuss/2010-January/001461.html

The rest of the consolidations will change in later builds, once
we see what issues ON hits, and the necessary infrastructure is
in place for delivering IPS packages from consolidations to the
central Release Engineering repository.  X, Desktop, & SFW are next
in line after ON, and have been working with Liane & the ON/IPS team
on planning for our changeovers.

I hope this helps with confusion people have had – if not, try asking
your questions on the appropriate OpenSolaris.Org mailing list or web
forum.

As of OpenSolaris build 130 NIS+ is officially no longer available, refer http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6874309