Hi,
How do I set-up /etc/default/autofs in Solaris 10 so that it allows the 
automountd start with the environment variable settings which we use in 
our Solaris 9  /etc/init.d/autofs.
I have failed by adding to /etc/default/autofs :-
PLATFORM=SunOS_5.8_sparc_all

The Solaris 9 init script start-up line looks like this:-
/usr/lib/autofs/automountd -D SERVER=brsfs01 -D 
PLATFORM=SunOS_5.8_sparc_all

-- 



Cheers

Richard Skelton
Richard.Skelton@infineon.com
Infineon Technologies UK Ltd
Infineon House
Great Western Court
Hunts Ground Road
Stoke Gifford
Bristol
BS32 8HP
Tel +44(0)117 9528808

Hi

Richard T Skelton wrote:
> Hi,
> How do I set-up /etc/default/autofs in Solaris 10 so that it allows the 
> automountd start with the environment variable settings which we use in 
> our Solaris 9  /etc/init.d/autofs.
> I have failed by adding to /etc/default/autofs :-
> PLATFORM=SunOS_5.8_sparc_all

That is supposed to work, according to autofs(4):

      <environment variable>=<value>

          Environment variables. Each  environment  variable-value
          pairing  must be on its own line. You can specify multi-
          ple such pairings. There  are  no  environment  variable
          settings supplied.

The following lab system is running recent Solaris 10 bits
(more recent than 69, but I don't know if anything relevant has
changed).

1. Add to /etc/default/autofs:

GRMTEST=qwerty

2. Restart autofs:

	# svcadm restart svc:/system/filesystem/autofs:default


	Aside: note that if you had chosen to kill automountd and
	start it on the cmdline with -D options you'd be
	out of luck - smf will see the death of automountd and
	restart it for you.

3. Check env of automountd:

# svcs -p svc:/system/filesystem/autofs:default
STATE          STIME    FMRI
online         16:44:04 svc:/system/filesystem/autofs:default
                16:44:04   205325 automountd

# pargs -e 205325
205325: /usr/lib/autofs/automountd
envp[0]: CPU=sparc
envp[1]: ARCH=sun4
envp[2]: PATH=/usr/sbin:/usr/bin
envp[3]: SMF_FMRI=svc:/system/filesystem/autofs:default
envp[4]: SMF_METHOD=/lib/svc/method/svc-autofs start
envp[5]: SMF_RESTARTER=svc:/system/svc/restarter:default
envp[6]: TZ=GB-Eire

4. Yup, no sign of GRMTEST in the environment :-(

5. gcore automountd and strings the core - GRMTEST is mentioned
    in there.

6. Appoint a new automount point in /etc/auto_master controlled
    by a executable map:

/grmtest        /aks

# cat /aks
#!/bin/ksh

set > /tmp/env

exit 1

7. cd /grmtest/foo

# cat /tmp/env
ARCH=sun4
CPU=sparc
ERRNO=25
FCEDIT=/bin/ed
IFS='
'
LINENO=3
MAILCHECK=600
OPTIND=1
PATH=/usr/sbin:/usr/bin
PPID=205325
PS2='> '
PS3='#? '
PS4='+ '
PWD=/
RANDOM=27091
SECONDS=0
SHELL=/bin/sh
SMF_FMRI=svc:/system/filesystem/autofs:default
SMF_METHOD='/lib/svc/method/svc-autofs start'
SMF_RESTARTER=svc:/system/svc/restarter:default
TMOUT=0
TZ=GB-Eire
_

So it doesn't go there.  Note that the standard variables seem to be
missing too: HOST, OSNAME, OSREL, OSVERS


8. Finally, let's see if it is available for expansion within maplines.

/grmtest2       auto_grmtest2

# cat /etc/auto_grmtest2
foo     /$GRMTEST/foo

	# cd /net/=v	(verbose on)
	# cd /net/=9	(lots of tracing)

	(This will show up in /var/svc/log/system-filesystem-autofs:default.log)

# cd /grmtest2/foo	(trigger the above)

In log file:

t16     LOOKUP REQUEST: Tue Nov  9 17:10:37 2004
t16       name=foo[] map=auto_grmtest2 opts= path=/grmtest2 direct=0
t16       PUSH /etc/auto_grmtest2
t16       POP /etc/auto_grmtest2
t16       mapline:      /$GRMTEST/foo
t16       do_lookup1: action=2 wildcard=FALSE error=2
t16     LOOKUP REPLY    : status=2
t1      LOOKUP REQUEST: Tue Nov  9 17:10:37 2004
t1        name=foo[] map=auto_grmtest2 opts= path=/grmtest2 direct=0
t1        PUSH /etc/auto_grmtest2
t1        POP /etc/auto_grmtest2
t1        mapline:      /$GRMTEST/foo
t1        do_lookup1: action=2 wildcard=FALSE error=2
t1      LOOKUP REPLY    : status=2
t17     LOOKUP REQUEST: Tue Nov  9 17:10:37 2004
t17       name=foo[] map=auto_grmtest2 opts= path=/grmtest2 direct=0
t17       PUSH /etc/auto_grmtest2
t17       POP /etc/auto_grmtest2
t17       mapline:      /$GRMTEST/foo
t17       do_lookup1: action=2 wildcard=FALSE error=2
t17     LOOKUP REPLY    : status=2

Hmmm, apparently busted.

9. Finally, reboot with the /etc/default/autofs changes in place in case
    the above is a question of how smf restarted automountd.  Nope.

A workaround until this is addressed is to edit the method script.
See the start exec method from 'svcprop svc:/system/filesystem/autofs'
which shows the start method is /lib/svc/method/svc-autofs.
Note that the intention is that you should generally need to
modify any of these method scripts - service properties or
other files in places like /etc/default should provide the
hooks you require.

> The Solaris 9 init script start-up line looks like this:-
> /usr/lib/autofs/automountd -D SERVER=brsfs01 -D 
> PLATFORM=SunOS_5.8_sparc_all

When /etc/default/autofs works again it will avoid you having to
edit the method script.  I'll log a bug and it will be fixed soon
I'm sure.

Cheers

Gavin

Gavin Maltby wrote:

> When /etc/default/autofs works again it will avoid you having to
> edit the method script.  I'll log a bug and it will be fixed soon
> I'm sure.

Bug 6193900 logged.

Gavin

Gavin Maltby wrote:

> Bug 6193900 logged.

This turns out to be a documentation issue.  The correct syntax
for /etc/default/autofs (not very well described in the file
itself or the autofs(4) manpage) is

AUTOMOUNTD_ENV=<name=value>

ie 'AUTOMOUNTD_ENV=' must prefix your assignment, eg

AUTOMOUNTD_ENV=MYTEST=yes

Some experimentation by the bug evaluator suggests that
there is still a bug here: you can't have repeated
assignment lines like the above (as the file says you
should be able to).

Gavin

Gavin Maltby wrote:

> Some experimentation by the bug evaluator suggests that
> there is still a bug here: you can't have repeated
> assignment lines like the above (as the file says you
> should be able to).

.... now fixed in what will be build 73.

Cheers

Gavin

Gavin Maltby wrote:
> Gavin Maltby wrote:
> 
>> Some experimentation by the bug evaluator suggests that
>> there is still a bug here: you can't have repeated
>> assignment lines like the above (as the file says you
>> should be able to).
> 
> 
> ... now fixed in what will be build 73.
> 
> Cheers
> 
> Gavin

Which will roughly equate to what release of Express? ;-)

Beardy wrote:

> Gavin Maltby wrote:
>
>> Gavin Maltby wrote:
>>
>>> Some experimentation by the bug evaluator suggests that
>>> there is still a bug here: you can't have repeated
>>> assignment lines like the above (as the file says you
>>> should be able to).
>>
>>
>>
>> ... now fixed in what will be build 73.
>>
>> Cheers
>>
>> Gavin
>
>
> Which will roughly equate to what release of Express? ;-)

Looks like it will miss *Solaris Express 11/04 :-(
See 
http://blogs.sun.com/roller/page/tpenta/20041123#solaris_express_11_04_is
*

-- 



Cheers

Richard Skelton
Richard.Skelton@infineon.com
Infineon Technologies UK Ltd
Infineon House
Great Western Court
Hunts Ground Road
Stoke Gifford
Bristol
BS32 8HP
Tel +44(0)117 9528808

Richard T Skelton wrote:
> Beardy wrote:
> 
>> Gavin Maltby wrote:
>>
>>> Gavin Maltby wrote:
>>>
>>>> Some experimentation by the bug evaluator suggests that
>>>> there is still a bug here: you can't have repeated
>>>> assignment lines like the above (as the file says you
>>>> should be able to).
>>>
>>>
>>>
>>>
>>> ... now fixed in what will be build 73.
>>>
>>> Cheers
>>>
>>> Gavin
>>
>>
>>
>> Which will roughly equate to what release of Express? ;-)
> 
> 
> Looks like it will miss *Solaris Express 11/04 :-(
> See 
> http://blogs.sun.com/roller/page/tpenta/20041123#solaris_express_11_04_is
> *
> 

Yup, I got the 11/04 blog today also. Ah well, I shall raise 
a glass to 01/05 (zilch happens in December)

Beardy <beardy@beardy.net> wrote:
> Yup, I got the 11/04 blog today also. Ah well, I shall raise 
> a glass to 01/05 (zilch happens in December)

Somehow I dont think there'll be an SX 1/05, given that S10 is due to
release then...

  Scott

Scott Howard wrote:
> Beardy <beardy@beardy.net> wrote:
> 
>>Yup, I got the 11/04 blog today also. Ah well, I shall raise 
>>a glass to 01/05 (zilch happens in December)
> 
> 
> Somehow I dont think there'll be an SX 1/05, given that S10 is due to
> release then...

True enough. I'm hoping for another proper S10 / S11 Beta 
program to kick off next year sometime.

Scott Howard <scott@hunterlink.net.au> writes in comp.unix.solaris:
|Beardy <beardy@beardy.net> wrote:
|> Yup, I got the 11/04 blog today also. Ah well, I shall raise 
|> a glass to 01/05 (zilch happens in December)
|
|Somehow I dont think there'll be an SX 1/05, given that S10 is due to
|release then...

Actually, I believe current plans call for Solaris Express to start
releasing builds of "the one after Solaris 10" (*) around the 1/05 or
2/05 release.

(*) The release most people call Solaris 11, but marketing says we're not
    allowed to use that name for it yet.  It won't be that much of a big
    leap at first, while most of us recover from S10, but that's where 
    you'll likely first see Project Janus and ZFS.

-- 
________________________________________________________________________
Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
 http://www.csua.berkeley.edu/~alanc/   *   http://blogs.sun.com/alanc/
  Working for, but definitely not speaking for, Sun Microsystems, Inc.

In article <co5c50$8n1$1@agate.berkeley.edu>,
	Alan Coopersmith <alanc@alum.calberkeley.org> writes:
> Scott Howard <scott@hunterlink.net.au> writes in comp.unix.solaris:
>|Beardy <beardy@beardy.net> wrote:
>|> Yup, I got the 11/04 blog today also. Ah well, I shall raise 
>|> a glass to 01/05 (zilch happens in December)
>|
>|Somehow I dont think there'll be an SX 1/05, given that S10 is due to
>|release then...
> 
> Actually, I believe current plans call for Solaris Express to start
> releasing builds of "the one after Solaris 10" (*) around the 1/05 or
> 2/05 release.
> 
> (*) The release most people call Solaris 11, but marketing says we're not
>     allowed to use that name for it yet.  It won't be that much of a big
>     leap at first, while most of us recover from S10, but that's where 
>     you'll likely first see Project Janus and ZFS.
> 

You guys have _got_ to get marketing to give up the prerogative to rename
any new version of any product.  So far, except for the 2.6 -> 7 confusion,
it hasn't been totally crazy with Solaris (although why they couldn't have
just stuck with SunOS 5.x is another story), but what they've done to
whatever-the-heck-the-compiler-suite-is-called-today causes a level of
confusion that could only be regarded as unproductive, and the iPlanet to
Sun One to Java whatever rebrandings have been problematic too (although
the iPlanet to Sun One at least made sense in terms of the Sun-Netscape
alliance having faded away). 


-- 
mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"