welcome: please sign in
location: Solaris10
==Development environment==
Almost the first thing to do is expand your path...
  bash-3.00# PATH=/usr/sfw/bin:/usr/ccs/bin:/opt/sfw/bin:/usr/bin:/usr/ucb:/usr/sbin:/usr/openwin/bin

GNU make is installed as /usr/sfw/bin/gmake so I currently consider it practical to
  bash-3.00# ln -s /usr/sfw/bin/gmake /usr/sfw/bin/make

==WebConsole / ZFS Admin==
So, for those who are un-aware of how to enable the service to accept connections, remotely, here's a quick and dirty:

  /usr/sbin/svccfg -s svc:/system/webconsole setprop options/tcp_listen = true

  /usr/sbin/svcadm refresh svc:/system/webconsole

  /usr/sbin/smcwebserver stop

  /usr/sbin/smcwebserver start

  /usr/sbin/svcadm enable svc:/system/webconsole

That should do it. Now make sure your port (6789) is listening to "All" (*):
  /usr/bin/netstat -an|grep 6789

*.6789 *.* 0 0 49152 0 LISTEN

Now open your web browser on your desktop machine (laptop, whatever) and go to the server:6789


==Building Cyrus-IMAP & Cyrus-SASL==
===Configure & make sasl...===

* SASL is apparently already installed with Solaris. Trying cyrus build without it...

  bash-3.00# make

Plugins are being installed into /usr/local/lib/sasl2,
but the library will look for them in /usr/lib/sasl2.
You need to make sure that the plugins will eventually
be in /usr/lib/sasl2 -- the easiest way is to make a
symbolic link from /usr/lib/sasl2 to /usr/local/lib/sasl2,
but this may not be appropriate for your site, so this
installation procedure won't do it for you.

If you don't want to do this for some reason, you can
set the location where the library will look for plugins
by setting the environment variable SASL_PATH to the path
the library should use.</pre>

=== Install Berkeley DB ===
Cyrus-Imap requires Berkeley db unless you use skiplist...
<pre>bash-3.00# cd build_unix/
bash-3.00# CC=gcc ../dist/configure
bash-3.00# make
bash-3.00# make install

===Configure & make cyrus...===
  bash-3.00# CFLAGS='-I/usr/include/kerberosv5' ./configure --with-bdb-libdir=/usr/local/BerkeleyDB.4.8/lib/ --with-bdb-incdir=/usr/local/BerkeleyDB.4.8/include/ --with-sasl=/usr/local --with-snmp=no

Mike tells me we use "skiplist" and not Berkeley DB so this should suffice:
  bash-3.00# CFLAGS='-I/usr/include/kerberosv5' ./configure --with-bdb=no --with-sasl=/usr/local --with-snmp=no

==Building Nagios==
  bash-3.00# CC=gcc ./configure --with-gd-lib=/opt/sfw/lib --with-gd-inc=/opt/sfw/include

edit / patch the configure script like this:
  +s,@SOCKETLIBS@,-lnsl -lsocket,;t t

====mysql_config bug====
In /usr/sfw/bin/mysql_config: (still broken as of nagios-plugins-1.4.15)
  -cflags="-I$pkgincludedir -xstrconst -mt " #note: end space!
  +cflags="-I$pkgincludedir " #note: end space!

  bash-3.00# ./configure –with-ssl=/usr/sfw/ –with-ssl-lib=/usr/sfw/lib/

NRPE 2.12 also assumes ALL unix has two log facilities at line 616-619 of ./src/nrpe.c:
else if(!strcmp(varvalue,”ftp”))

Test DNS:
  testsol.mustang.morningside.edu CNAME sol10u8-devel.mustang.morningside.edu
  (--[[User:Meyersh|Shaun Meyer]] 23:48, 16 November 2009 (UTC)) 

*Copying the samba configuration from fs, dropping a hostname into /etc/nodename so we got something useful on boot, and adding DNS allowed us to net ads join painlessly.

*Adding winbind to /etc/nsswitch.conf worked as expected 

*Winbind (I presume) created an /etc/pam.conf-winbind which I moved into /etc/pam.conf and now authentication works as expected.

Root access is enabled in the same way as Linux in /etc/ssh/sshd_config:
<pre>--- sshd_config.orig    Mon Nov 16 17:47:40 2009
+++ sshd_config Mon Nov 16 17:46:06 2009
@@ -125,7 +125,7 @@
 # Note that sshd uses pam_authenticate(3PAM) so the root (or any other) user
 # maybe denied access by a PAM module regardless of this setting.
 # Valid options are yes, without-password, no.
-PermitRootLogin no
+PermitRootLogin yes

 # sftp subsystem
 Subsystem      sftp    /usr/lib/ssh/sftp-server

==Patching from the commandline==
The following is an example of patching done on Solaris 10, running on an Ultra2 workstation (in preperation for SC3.1):

<pre>root@cuddluster1 /$ smpatch analyze
120199-01 SunOS 5.10: sysidtool Patch
119145-02 SunOS 5.10: usr/snadm/lib Patch
root@cuddluster1 /$ smpatch download
120199-01 has been validated.
119145-02 has been validated.
root@cuddluster1 /$ smpatch update
Installing patches from /var/sadm/spool...
120199-01 has been applied.
119145-02 has been applied.

It doesn't get easier than that. You can easily and safely automate this if you choose to. Patching, the way it should be.

Note that (currently) you do not need to be a Sun customer to patch. There are some caviates to this, but you can get plenty of patches to keep you happy even without a support contract (which is worth having anyway). If you have a Sun contract its easy to specify that information to smpatch:

<pre>root@cuddluster2 /$ smpatch set patchpro.sun.user="jschwartz" patchpro.sun.passwd="bigboss"
root@cuddluster2 /$</pre>

You might notice that when you are updating (applying the patches) that some patches complain about being against policy. Patches are all classified as being 'standard' or 'nonstandard'. Standard patches are your garden variety and safe to install via smpatch without much concern, just reboot as soon as you can to make sure everything is effective. Nonstandard patches on the other hand are ones that either are interactive during install, or associated with the properties: rebootafter, rebootimmediate, reconfigafter, reconfigimmediate, or singleuser. In otherwords, these patches shouldn't just be tossed into the system without a knowing eye keeping watch.

<pre>118548-01 has been applied.
NOTICE: Patch 118370-02 cant be installed because its type is prohibited by policy.
118852-01 has been applied.</pre>

If you look up the patch above you'll see that is a patch for ibmf and requires an immediate reboot following install, which is why its against the default policy. Patches that are outside of the default policy should be downloaded (like above) but installed in single user mode or explicitely when you are not running in production. You can do this by setting the SMpatch 'patchpro.install.types' property and then updating, specifying which property types (such as 'rebootimmediate') should be applied. All this gives you fine grained control but doesn't consume days of your time, allowing you to keep up to date without fear and without lengthy outages that interfere with operations.

For more information please see the smpatch(1M) man page.

==xterm-color support==
[geeks] xterm-color and Solaris
Nathan Raymond nate at portents.com
Thu Feb 3 18:01:17 CST 2005

    * Previous message: [geeks] Re: [rescue] Complete VoIP setup for sale
    * Next message: [geeks] xterm-color and Solaris
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I have a cousin going to Syracuse University, and students there are 
running into a problem when they log into their Solaris shell accounts 
from MacOS X machines.  In Mac OS X 10.3, Terminal.app defaults to 
xterm-color for the TERM type, and the Mac lab administrators have left it 
that way.  The UNIX admins there are running Solaris 8 for the servers 
that students log into, and Solaris 8 doesn't know about xterm-color. 
The Solaris systems respond this way to students logging in from 

  Type xterm-color unknown
  TERM = (unknown)
  Common terminals are vt52, vt100, sun, h19

  Terminal Type [vt100]:

My cousin says a lot of students don't know what to do when faced with the 
"Terminal Type [vt100]:" prompt, and either sit their staring at it, or 
start typing in command line options and this is what happens:

  TERM = (unknown) pine
  Type pine unknown
  TERM = (unknown) pine
  Type pine unknown

It never falls back, so no matter how many commands students enter in, 
they're stuck and often don't realize they're not in the shell yet.  The 
administrators haven't added anything to the MOTD to alert students about 
what to do, so they're just confused.

My cousin wants the admins to do something about it on their end - what is 
the best suggestion he can make to them about what to do?  I found this:


Which mentions this:

"9. If you dont have the file already, drop xterm-color in 
/usr/share/lib/terminfo/x/term-color. Then when/if you use a 
color-supporting xterm, you will be able to correctly set TERM=xterm-color 
and actually have it work properly. (This actually works better for dtterm 
color than its own "dtterm" TERM setting?!!)"

Which provides a link to this:


Is that what the Solaris admins should download and install on the server 
end of things to best resolve this?

On a similar topic, anyone know the best way to go around supporting 
xterm-color in netbsd?

Thanks in advance for any info,

Solaris10 (last edited 2011-02-08 16:26:32 by localhost)