My Linux desktop is drifting forwards in time - and it is causing me no end of grief. Okay, I'll use rdate against my opteron to fix the time. Note that I could probably manually sync the time, but eventually I'll want them to stay automatically synced. Okay:

[tdh@adept ~]> sudo rdate wont
rdate: couldn't connect to host wont: Connection refused

No problem, I just need to wont, edit /etc/inetd.conf and I'll be able to sync up. But wait, we now have smf to deal with:

#ident  "@(#)inetd.conf 1.57    05/06/08 SMI"
#
# Legacy configuration file for inetd(1M).  See inetd.conf(4).
#
# This file is no longer directly used to configure inetd.
# The Solaris services which were formerly configured using this file
# are now configured in the Service Management Facility (see smf(5))
# using inetadm(1M).

Okay, the first time through, I missed the part about inetadm(1M), but bear with me. I saw that it was no longer used, actually I already suspected that. So I asked svcs to tell me about it:

[tdh@wont /etc]> svcs | grep time
[tdh@wont /etc]> svcs | grep date

Hmm, I knew it was the timed daemon I wanted to kick off. I also manually scanned the list:

[tdh@wont /etc]> svcs | more

No luck. Okay time to check the man pages:

...
     The inetd daemon responds to rdate requests. To enable inetd
     response,  the lines invoking the time command in inetd.conf
     must not be commented out.
...

Honestly, the man page is now out of date and should be fixed up. Note I've missed the crucial piece of evidence earlier inside /etc/inetd.conf. And the man page for inetd.conf(4) would apply the clue bat as well. At this point, I googled and found Solaris Forums - New to Solaris 10 - inetadm and svcadm huh (how to enable telnet). And while the title clearly point me to inetadm(1M), it took me a bit.

Once I got there, I had a bit of a hard time working inetadm:

[tdh@wont /etc]> sudo inetadm | grep time
disabled  disabled       svc:/network/daytime:dgram
disabled  disabled       svc:/network/daytime:stream
disabled  disabled       svc:/network/time:dgram
disabled  disabled       svc:/network/time:stream
[tdh@wont /etc]> sudo inetadm enable svc:/network/time:dgram
Usage:
  inetadm
  inetadm -?
  inetadm -p
  inetadm -l {FMRI | pattern}...
  inetadm -e {FMRI | pattern}...
  inetadm -d {FMRI | pattern}...
  inetadm -m {FMRI | pattern}... {name=value}...
  inetadm -M {name=value}...
[tdh@wont /etc]> sudo inetadm svc:/network/time:dgram
Usage:
  inetadm
  inetadm -?
  inetadm -p
  inetadm -l {FMRI | pattern}...
  inetadm -e {FMRI | pattern}...
  inetadm -d {FMRI | pattern}...
  inetadm -m {FMRI | pattern}... {name=value}...
  inetadm -M {name=value}...

The syntax was not the same as svcadm(1M). I was in a rush, but the forum had a nice tidbit:

I believe svcadm delegates to inetadm, so you needn't
worry in this case about inetadm.

Okay, lets try that:

[tdh@wont /etc]> sudo svcadm enable svc:/network/time:dgram
[tdh@wont /etc]> sudo inetadm | grep time
disabled  disabled       svc:/network/daytime:dgram
disabled  disabled       svc:/network/daytime:stream
enabled   online         svc:/network/time:dgram
disabled  disabled       svc:/network/time:stream
[tdh@wont /etc]> sudo svcadm enable svc:/network/time:stream
[tdh@wont /etc]>

And lets verify with the client:

[tdh@adept ~]> sudo rdate wont
rdate: [wont]   Fri Mar 31 16:28:06 2006
[tdh@adept ~]> date
Fri Mar 31 16:35:20 CST 2006
[tdh@adept ~]> sudo rdate -s wont
[tdh@adept ~]> date
Fri Mar 31 16:28:23 CST 2006