FYI

One thing that I have noticed in going from Amanda 2.5.2p1 to Amanda 2.6.1p1 on 
a Solaris 10 box is that some of the paths have changed. The most important is 
libexec. Under 2.5.2p1 amandad amindexd amidxtaped all resided under libexec. 
Under Amanda 2.6.1p1 they reside under libexec/amanda.

Not a problem except that you have to remember to modify your SMF entry for 
amandad amindexd amidxtaped and correct the "exec" path. 

[57][root@zorn]:~amanda# inetadm -l svc:/network/amanda/udp:default
SCOPE    NAME=VALUE
         name="amanda"
         endpoint_type="dgram"
         proto="udp"
         isrpc=FALSE
         wait=TRUE
         exec="/local/Amanda/amanda/libexec/amandad -auth=bsd amdump amindexd 
amidxtaped"
         user="amanda"
default  bind_addr=""
default  bind_fail_max=-1
default  bind_fail_interval=-1
default  max_con_rate=-1
default  max_copies=-1
default  con_rate_offline=-1
default  failrate_cnt=40
default  failrate_interval=60
default  inherit_env=TRUE
default  tcp_trace=FALSE
default  tcp_wrappers=FALSE
default  connection_backlog=10


This bit me when I went to test V2.6.1p1 from V2.5.2p2, as amandad is now under 
libexec/amanda. So for now I have to play some ln games so that I do not have 
to change the "exec" entry when I switch between Amanda version that have 
different libexec paths.

Just a heads up.

Robert


_____________________________________________________________________
Robert P. McGraw, Jr.
Manager, Computer System                    EMAIL: rmcgraw AT purdue DOT edu
Purdue University                            ROOM: MATH-807
Department of Mathematics                   PHONE: (765) 494-6055
150 N. University Street                      
West Lafayette, IN 47907-2067            
 

> -----Original Message-----
> From: owner-amanda-users AT amanda DOT org [mailto:owner-amanda-
> users AT amanda DOT org] On Behalf Of Chris Hoogendyk
> Sent: Wednesday, May 20, 2009 4:30 PM
> To: amanda-users AT amanda DOT org
> Subject: Re: PLEASE DISREGARD FOUND THE PROBLEM-amcheck error on local
> server
> 
> 
> 
> 
> Dustin J. Mitchell wrote:
> > On Wed, May 20, 2009 at 3:13 PM, Peter Kunst
> <peter.kunst AT swissrisk DOT com> wrote:
> >
> >> Whenever this happens again on Solaris 10, not getting a service out
> of
> >> maintenance mode even when amanda logs say all is ok, it might help
> to
> >> remove/delete this service and create it from scratch.
> >>
> >> I've traced one of those issues down to some kind of sqlite stuff
> >> getting confused (which is used by smf(5) IMHO).
> >>
> >
> > This is good info.  Robert or Peter, do you want to add it to the
> > wiki?  I feel like we should have a more extensive "Amanda on
> Solaris"
> > section, but I'm certainly unqualified to write it..
> 
> Solaris 10 is a whole new ball of wax for a sysadmin.
> 
> I've created a number of services, but still have a lot to learn. One
> important thing to note is the whole chain of dependencies and run
> levels  that affect a service. You can write a simple service that has
> no (or claims no) dependencies, but that isn't really the way they are
> supposed to work. It's sort of like building error checking and
> pre-conditions into code.
> 
> Just as an example, I cloned a system this week by replicating the boot
> drive, moving the drive to another system, and replicating that back
> over the boot drive. Then boot off CD and edit all the /etc identity
> stuff. I forgot to remove some entries from /etc/vfstab where the first
> system had a larger collection of drives. It booted up and none of the
> services came up. It turns out that the file system is a dependency for
> the multi-user run level, which in turn is a dependency for many of the
> services. So, the extra file systems, that I didn't need, ended up
> blocking all the services. On a Solaris 9 system, that would have just
> flown by.
> 
> You can see the full list of dependencies for a service by doing `svcs
> -l <service name>`. Of course, that's recursive. Some of those might
> have dependencies as well. It's sort of like tracking the loading of
> libraries and their dependencies with ldd.
> 
> --
> ---------------
> 
> Chris Hoogendyk
> 
> -
>    O__  ---- Systems Administrator
>   c/ /'_ --- Biology & Geology Departments
>  (*) \(*) -- 140 Morrill Science Center
> ~~~~~~~~~~ - University of Massachusetts, Amherst
> 
> <hoogendyk AT bio.umass DOT edu>
> 
> ---------------
> 
> Erdös 4
> 
>