mmmmn

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://mmmmn.blogbus.com/logs/1909602.html

1、>Unfortunately, I don't have the command isainfo in my system, any
>alternative way I can check
>the kernel bit?

If you don't have "isainfo" on your system, you are running
Solaris 2.6 or earlier and consequently you run it in 32 bit mode.

Casper

2、
> JET (jumpstart enterprise toolkit) considered not good enough
>
>
> Somebody told me to investigate JET to help with zones.
> I did. I didn't like what I found.

That would be me

>
> I don't expect my problems with the software to get fixed.

Why not ?

Any reasonable request to jet@xxxxxxx should get a response.

> But my complaints about the docs really should be considered.
>
> the docs
>
> I get the impression that JET wants to hide the gears
> and pulleys of jumpstart--just config this one file and you're done.
> Whether that impression is correct or not, it's a terrible mistake
> to use different terminology between Sun's guide and JET. It means
> that if you want to find out what they each say about "whatever,"
> you'll have to first decipher what "whatever" is called in each one
> first. And that's always discouraging. In particular:
>
> The JET docs call the machine being installed the "target server."
> (The guide tends to just call them systems--fair enough, that's pretty
> darn generic, too.) Every time I look at it I balk at the word "server."
> There are already a swarm of servers in the Solaris Adv. Installation

Guide,
> but none of them are "target" servers. Tossing in the word server
> means there's just one more way you can guess wrong about the role
> of the machine. Consider that "target" by itself says what the machine is.
> The word "server" doesn't add anything--I won't back down on that--and
> I feel very strongly that it __subtracts__ clarity.
> (a) The thing being installed isn't __serving__ anything.
> It's not even running until it's rebooted. (Yeah, yeah, you know what I

mean.)
> (b) Even once the target is up, it may be a client machine
> and not a server. Might we have missed something? Is it possible
> that only servers can be installed with JET/jumpstart? Probably not,
> but it wouldn't be the first time documentation omitted explicit
> mention of a restriction like that and expected you to infer from
> such terminology. And we know that if you try to track down an
> explicit answer to that question you won't find it. So JET provokes
> a question that isn't answered anywhere. That's going to be
frustrating.

Your comments may be valid, perhaps they are aimed at the wrong audience ?
Surely these comments should be directed to jet@xxxxxxx ?

> Pity the poor newbies.

They can use the bigadmin get and and go page :-)

http://www.sun.com/bigadmin/content/jet/

>
> And given that all that can be avoided by __neglecting__ to
> put in a useless word.... If you just gotta, call it the target

__machine__.
>
> The JET docs say JS_SOLARIS_DIR is the "location of the Solaris
> images." Sounds good, until you begin to go about the business of
> filling up that dir. Can I have a dir for Solaris 8 versions, a dir
> for Solaris 9 versions.... ? Or do all the versions need to be
> side-by-side? (Does JET know how to look down a directory tree?
> If that search is done clumsily it could be very time consuming.
> How deep does it look? Maybe I missed them, but I didn't see answers
> to those.)

The media is stored under (by default) /export/install/media/<solaris
version>

It is not a "tree walk" but a directory reference , see
/opt/SUNWjet/etc/solaris_locations (page 10 and 14 of the document)

So, not time consuming

>
>
>
> the software
>
> Configuring a machine means editing a big shell script. That
> single shell script has __everything__ (or at least a lot) in it. That's

It is not a shell script, but a list onf name and value pairs, otherwise
known as a template.

If fact, for speed a minimum of 5 values need to be set in the base_config
template to create a client.

Also, when making the template specify which modules are required to cut
down on size
ie make_template <client> zones
will give base_config and zones only (page 17 of the document)

> not to my taste, but not everyone needs to agree with my taste in
> such matters. What is truly bad is that it means that if I'm to use
> JET, I'm going to have to re-do all my stuff. All my profiles,
> sysidcfgs, ... I had layered my own level of stuff on top of existing
> jumpstart, like a file per machine that listed packages (my own) to add.

JET can be installed "alongside" an existing JumpStart infrastructure,
there is no need to re-do all your stuff and if you decide to transition
then you can do it in your own time and use the custom module (page 21) for

your own
scripts.

> I could live with losing those. I'd have to convert, but that's part
> of doing business. But JET basically expects me to throw out the files
> I made according to Sun's installation guide. And that's going too far.

No where does it say you have to throw out any existing JumpStart

> (a) Did this part of the wheel really need reinvention?

It is not a re-invention, it is a Toolkit

> (b) On x86 one of the things you can put in sysidcfg is the
> video card description. Even if there's a way to put that in JET
> (not in the docs) I'll be dipped if I want to bother with __that__.
> According to me, there's lost functionality.

The sysidcfg lives in /opt/SUNWjet/Clients/<client>

(Page 12 and 33)

> (c) In Sun's profile I can do things by cylinders. Tiresome,
> but that's what I do. I'm probably in the minority on this. JET

Not documented, but the name value in the template file is in fact in the
format exxpected in the profile, so yes it can still be done.

> won't let me use cylinders. If I want to set up mirrors I can do
> precisely what I want and I don't have to worry about "roundoff".
> (I don't rely completely on Sun's mirroring technique in the profile
> file--mine predates the one Sun did.)

Again, you can if you so wish amend the profile in the client directory
pre-build.

(page 12 and 33)

> (d) I can put swap on the cylinders I want, starting at zero.
> JET won't let me--though it's possible the Solaris install would rescue
JET.
Yes JET will allow you to place swap on what ever cylinders you want to

> I don't like /opt on slice 7 or whatever it was they did.
> I want it where I want it, and that freedom has been taken from me.
> Same remark for some of the other partitions.

I fail to see how you feel freedom has been removed, if you don;t like
/opt on s7, then move the reference to where ever you want it to be.
ie
base_config_profile_s6_mtpt="/opt"
base_config_profile_s6_size="2048"

Personally, I never have a separate /opt partition

> (e) Is there a way to delete packages? Add packages?

Yes, the custom module (page 21)

Or in the template for Solaris media
############
#
# Packages to add to/remove from the selected cluster
#
# Use this to populate the profile with package <pkg> <add|delete> entries
#
base_config_profile_add_packages=""
base_config_profile_del_packages=

> At the profile level, I mean. If I've got to go edit some profile
> they're going to generate, then I don't see that shoving part of
> what I want in that script and then going to edit a profile saves
> me anything. (It might save __you__ something, but I have a script
> to help with profiles.)

That is what JET does, you edit the template, it builds the profile for
you

>
> If I want to set up machine CCC using AAA's profile and BBB's
> list of 3rd party packages, using my way I can just copy the profile
> and pkglist. Using JET, I've got to cut-and-paste. cp and edit vs.
> cut-and-paste and edit isn't rocket science, but if I want to keep

You are right, it isn't rocket science, just run
make_template -T <client> <client>

(Page 21 of the document)

> the JET file's sections in the same order I'll have more positioning
> within that file to do than with separate files (my way). I grant
> that's hardly going to matter to the gross domestic product. But,
> be fair, if I get interrupted it'll be easier for me to see by doing
> an 'ls' how far I got in setting up CCC than it will be for JET to
> edit a file and see what sections have been done. Yuck. But that
> is a matter of taste.

Taste has nothing to do with reading the manual.

>
> The rules (rules.ok) file now has a reserved role in JET.
> The things I did with rules.ok must now be redone. (Or, I'll have
> to investigate JET to see if what I do will break their stuff.
> There's a project I don't need.)

JET can live with your current JumpStart, bit can use theri own rules
file. The rules file in JET is simple, it handles *all* hardware.

>
> What, exactly, does JET do to get this stuff done? I know
> what jumpstart does, I presume they use the begin/profile/finish/sysidcfg
> a lot like I do. They add an rc script, a lot like I do. My way,
> I know where the profile is. If I want to run a check on the profile,
> I can. Where's the JET one? Presumably JET writes and uses a finish

The profile is in the Clients/<client> dir as documented in the document
on pages 12 and 33

> script. Where is it? How will I know which finish script goes with
> machine xxx? Which begin script? JET, in several different ways,
> takes control out of my hands. Some things can't be done during

JET utilsise a begin(and finish) script, which then calls the specific

actions
required depending on the modules used.

> jumpstart, they need to be done after boot. I, and JET, both put
> in rc scripts to handle that. Where are JET's? I know where mine
> is. Could I go hunting and find them? Yeah, but why do I have to
> __hunt__?? Why not __tell__ me up front? The docs are silent about
> such stuff--so that means their attitude is I don't have to know.

Read Chapter 8, Creating Modules.

That with reference to the document will guide you to the workings. But
there is in fact only 1 rc script, S99jumpstart.

> And that, in turn, means if I have to debug whatever, or want to add
> a feature, I've got to reverse engineer JET. There's a project I
> don't need.

In the template, it is taken car of
#
# Last one - mainly for developing JumpStart scripts!
#
# If you set this, the rc3.d/S99jumpstart script will be disabled
# (set to rc3.d/s99jumpstart) every time it is processed - this allows you
# to run it by hand and invoke each reboot step
#
base_config_debug_jumpstart_postinstall="

>
> I have over a hundred packages I've produced. Some of them
> have request scripts, and, therefore, require a response file if I'm
> to add them without interaction. I'm pretty sure there's no way for
> me to do that in JET. Now I've got to rework ten-fifteen packages.

Sorry, wrong again

> Or otherwise adjust. There's a project I don't need.

The template would have given you a clue

# Which additional packages are to be installed
# (by default, these get added during the main Solaris installation phase)
#
# O.S. Specific versions:
# as a side effect, if a directory exists under the package dir named
# after the OS, (uname -r), the subdirectory will be used instead of the
# main package directory
#
# i.e /export/install/pkgs/custom/sparc/5.8 takes preference over
# /export/install/pkgs/custom/sparc for a Solaris 8 box
#
# Package Response files:
# If a custom package needs a response file, create a directory called
# /opt/jet/Clients/<clientname>/responses
# and put the response file in to it, named the same as the package.
#
# i.e. for a package called Fred, on client1, use pkgask to create
# pkgask -r /opt/jet/Clients/client1/responses/Fred Fred
#
# (Space seperated list of packages)
#
custom_packages="
>
> Eons ago, before there was JET, the only advice you could get
> on jumpstart was a way to lay out the directory structure--profiles
> here, sysidcfgs here, and so on. So that's what I did. JET ignores
> that altogether. True, the previous advice wasn't terribly helpful,
> but on the other hand, since I (others?) used it, and since it's now
> being thrown out, it means anything I built on top of my old advice
> is now worthless. True, that can happen with any upgrade. But JET
> doesn't replace the old advice with something better (though perhaps
> it could be taught to use the old advice). I don't see that ignoring
> the old advice has been an upgrade. It feels changed purposelessly.

You are corrct, JET does not replace any of the old advice, it enhances
it. layouts change over time, FS Standard layouts change, JET can change
with it, just alter your template and run make_client

>
> What kinds of things have I built on top of the old scheme?
> I have some quality controls, not very elaborate. I have 4-5-6 perl
> scripts that can set up a machine for me. To begin doing the same
> thing in JET I'd have to parse the template file. If anybody knows

vi
read and edit it
make_client <template>

As directed by the document and the bigadmin page.

So, thats 2 commands, an editor of your choice and make_client

> how to do that, I do. (I have a program running now with three lexers
> and two parsers in it.) But I don't want to. I had ambitions of
> one day writing a program that would help me minimize the software
> installed on a machine to make it a little more secure. To do that,

JASS, of which there is a JetJASS module

> I'll have to parse the script and then do all the other work I'd have
> to do anyway, so all it's done is add work. I wanted to get closer,
> not farther away. There's a project I don't need.
>
> I wanted help/advice about my plan to jumpstart zones. There's
> a zones module, but how does it work? No docs. I suspect my own

JetZONES has come after the doc was written.
If you did a simple build (base_config) and then added zones
(make_template -f -T <client> <client> zones )
you could then edit the template and see what is needed.

But essentially the zone is a client in its own right, so before running
make_client on a template containing zones you also have to do a
make_zones_template / edit it/make_zones_client on the zone.

If this was not clear from the internal documentation in the zones
templates
############
#
# Give a list of zone names to create; this will be the 'nodename' for
# the zone; it is expected that you will create these zones using the
# 'make_zone_template' and 'make_client_template' commands.
#
# i.e. zone1 zone2 zone3 my-zone
#
zones_names=""

Then you should have asked at jet@xxxxxxx

> efforts are ahead of what JET can do. if I could benefit by plundering

I doubt it.

> JET's zones, where do I go? To find out what I want to know I'll have
> to reverse engineer JET. There's a project I don't need.

As mentioned in the doc, bigadmin and my original reply jet@xxxxxxx for
aditional help

>
> summary
>
> JET takes controls from me. It limits what I can do. It hides
> how it operates. It changes things without improving them. The docs
> can be counter-productive.
>

You mention all about your JumpStart setup and scripts, do you have any
documentation to enable others to make quick and easy use of it ?

> This shop stands a non-trivial chance of going all linux. So
> what I think may not matter anyway.

What ever floats your boat (or shop) , it is horses for courses.

JET can also be used to kickstart linux if you are interested :-)
------------------
> In article <pan.2006.01.10.16.38.43.613771@xxxxxxxxxxxxxxxxxxxxx>,
> Bruce Porter <bdp@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>On Mon, 09 Jan 2006 19:49:14 +0000, Jay G. Scott wrote:
>
> [snip]
>
>>
>>>
>>
>>JET can be installed "alongside" an existing JumpStart infrastructure,
>>there is no need to re-do all your stuff and if you decide to transition
>>then you can do it in your own time and use the custom module (page 21) for

your own
>>scripts.
>
> yeah. i never thought of that. it does mean, though, that i'll be changing
> my "record" and that, at least for a time, i'd have two kinds of data about
> how things were installed. not to my taste.
>
> looks like most/all of my other complaints were addressed. maybe the
> template i saw was old/misleading. i managed to get it wrong.
> certainly the one i read says:
> # if partitions are not required simply leave blank. In order to maintain
> # consistency the partitions will always use the same slice number:
> #
> # / s0
> # swap s1
> # /var s5
> # /usr s6
> # /opt s7
>
> and there's only a "size" not a start/size for cylinders. the way the

profile
> works using just one number means you're not using cylinders.

Its a simple guid for people to use, you can fill out any disk profile
entry infomation in, for instance "preserve"
>

> okay. if i'm wrong i'm wrong.
>
>
> i would still characterize this as a redesign because the inputs to
> JET and non-JET jumpstart are so different. i don't like having everything
> in one file for reasons i've covered. since JET doesn't replace, it just
> uses jumpstart, it can't __amplify__ on what jumpstart does. (if jumpstart
> can't do X then putting it in JET won't make X possible.) so the
> question becomes: is JET easier? i can see how it would be for some.
> you win.

Again , I need to correct you. JET does *amplify* on what JumpStart does.

It can do dootp,dhcp and grub (newboot) based installs, automatically
updating the dhcp server.

The freely available download is just a subset of what JET can do, for IPR
reasons a lot more modules are held back.
(ie Sun can charge consultancy for them during a build)

One major module is JetSC3. a very easy way of setting up a cluster, hands
free.

Other modules available (from Sun) are:-

JetALOM JET alom module
JetDHCP Jet dhcp product
JetIDS JET ids product
JetIPF JET IP-Filter supportn
JetJASS JASS product
JetLGTO Legato Networker Support
JetMaster JET Master module
JetN1GE JET n1ge product
JetNBUCLI JET NetBackup support
JetNEWBOOT JET Newboot product
JetRBAC JET RBAC product
JetRELMGT JET Release Management
JetRSC Jet rsc product
JetSAN JET san product
JetSBU Jet sbu product
JetSC3 JET sc3 Product
JetSC3RAC JET Sun Cluster 3 / Oracle RAC
JetSSEFS JET ssefs product
JetSSH SSH product
JetSUNMC JET sunmc product
JetSUNRAY Sun Jumpstart Enterprise Toolkit Sun Ray module
JetSlave JET Slave module
JetVPN JET vpn product
JetVTS JET VTS product
JetVXFS VxFS product
JetVXVM JET VXVM product
JetVXVM4 JET VXVM4 product
JetZONES JET Zones module

>
> [snip]
>
>>
>>--
>> Bruce
>>
>>"The internet is a huge and diverse community and
>>not every one is friendly"
>> http://www.ytc1.co.uk
>>

--
Bruce

3、Thanks so much for the response. My responses are inline.

> 1. Is link up?
>
> # ndd -set /dev/hme instance 0
> # ndd -get /dev/hme link_speed
1

> # ndd -get /dev/hme link_mode
1

> # ndd -get /dev/hme link_status
1

>
> (First = 10 or 100 mbit, second = half or full duplex, third = link up
> or down)
>

> 2. What does 'arp -an' look like?

Here is the full output, but it took a very long time.

(devito is the machine name of the machine in question)

arp -a

Net to Media Table: IPv4
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 172.xx.3.183 255.255.255.255 08:00:20:ac:1a:3d
hme0 172.xx.3.240 255.255.255.255 00:0e:0c:5b:ac:d0
hme0 172.xx.3.221 255.255.255.255 00:90:27:36:b4:ef
hme0 172.xx.3.220 255.255.255.255 00:07:e9:56:d7:55
hme0 172.xx.3.51 255.255.255.255 00:0c:41:e9:40:ca
hme0 devito 255.255.255.255 SP 08:00:20:ee:09:82
hme0 172.xx.3.7 255.255.255.255 00:d0:b7:06:c4:88
hme0 172.xx.3.1 255.255.255.255 00:03:9f:c7:b0:14
hme0 172.xx.3.124 255.255.255.255 00:d0:b7:91:2e:04
hme0 172.xx.3.69 255.255.255.255 00:04:23:25:c1:b7
hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00

>
> 3. You have pung (pinged, heh) from another machine **ON THE SAME
> SUBNET**? You mentioned 'network' but wasn't clear if also same subnet
> or not.

I tried pinging both from the same subnet as well as other subnets.
Same failure.

>
> 4. Do other machines on the same subnet ping the gateway ok? Depending
> on how the router is configured, it is possible to have ping traffic
> ACL'd off like we do here.

Another machine in the same subnet can ping the gateway succesfully

>
> 5. When you look at the reported MAC address for your IP in 'arp -an'
> output, does it match what 'ifconfig hme0' says for MAC address?

yes

>
> I've seen a forgotten machine with same IP cause this kind of flakiness
> in the past.
>
> 6. Is host connected to a switch or hub? 10 mbit or 100 mbit?

switch at 100mbit I believe, but I am not certain. I dont have easy
access to the switch. I can try and find out if it is important. The
computer is a company computer attached to a company network.

>
> 7. What is your host's settings for hme0?

ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index
2
inet 172.xx.8.40 netmask ffffff00 broadcast 172.xx.8.255
ether 8:0:20:ee:9:82

> Autonegotiated or hardcoded setting for speed and duplex?

There is nothing set in /etc/system, so I believe autonegotiated

>
> 8. Is the switch managed (expensive) or unmanaged (cheap)? If managed,
> is the switch port set to auto or to a specific speed or duplex setting?
> If hardcoded, what is its settings for that port?

I believe it is managed. But I don't know the answers to the other
questions -- I don't believe I have access to the switch.

>
> 9. Check the error counters to see if any unusually bad counter leaps out.
>
> # netstat -k eri0
>
> (If you do not know how to read the counters, post the output. Someone
> here would be more than happy to tell you if anything looks really bad.)

Here is the output:

netstat -k hme0
hme0:
ipackets 1329 ierrors 0 opackets 88 oerrors 0 collisions 0
defer 0 framing 0 crc 0 sqe 0 code_violations 0 len_errors 0
ifspeed 100000000 buff 0 oflo 0 uflo 0 missed 0 tx_late_collisions 0
retry_error 0 first_collisions 0 nocarrier 0 nocanput 0
allocbfail 0 runt 0 jabber 0 babble 0 tmd_error 0 tx_late_error 0
rx_late_error 0 slv_parity_error 0 tx_parity_error 0 rx_parity_error 0
slv_error_ack 0 tx_error_ack 0 rx_error_ack 0 tx_tag_error 0
rx_tag_error 0 eop_error 0 no_tmds 0 no_tbufs 0 no_rbufs 0
rx_late_collisions 0 rbytes 97044 obytes 3696 multircv 11 multixmt 0
brdcstrcv 1318 brdcstxmt 90 norcvbuf 0 noxmtbuf 0 newfree 0
ipackets64 1329 opackets64 88 rbytes64 97044 obytes64 3696 align_errors
0
fcs_errors 0 sqe_errors 0 defer_xmts 0 ex_collisions 0
macxmt_errors 0 carrier_errors 0 toolong_errors 0 macrcv_errors 0
link_duplex 0 inits 5 rxinits 0 txinits 0 dmarh_inits 0
dmaxh_inits 0 link_down_cnt 0 phy_failures 0 xcvr_vendor 524311
asic_rev 193 link_up 1

>
> 10. I've had people use an unauthorized/unapproved crimper that was
> *NOT* ratcheting when they made the Cat5 ethernet cables. Non-ratcheting
> crimpers don't make a good crimp.
>
> So about a year later, we started getting systems dropping off the
> network at odd times, usually when some traffic was present. Turns out
> the connector had come slightly loose and had to be re-crimped with a
> ratcheting crimper. No problems since then.
>
> 11. If it's a managed switch, what do the port interface counters show?
> Errors like collisions, framing, etc...?

Again, I don't believe I have access to the switch (although I can
check).

>
> Some ideas -- that should get you started. :)
>
> -Dan

Thanks!

4、>I am trying to make a stty setup that behavies in the exact same way
>as a working tip connection does.
>
>The tip connection is as below:
>:dv=/dev/dty/b002s:br#4800:pa=even:el=^C^S^Q^U^D:ie=%$:oe=^D:
>
>and the stty setup is as below:
>port_char="4800 cs7 parenb igncr ignbrk istrip"
>
>Although the stty works on one site but on others it fails when
>receiving long messages but using a tip connection as above works
>without any problem so something must be different in the setup.
>

Run tip on the port, then in another session on the same machine,
run 'stty -a < /dev/dty/b002s'. That will give you the settings
on the port while tip is running.

You mention of "long messages", but don't mention how long they are.
Based on that, I would guess that the difference is the XON/XOFF
flow control that tip enables ("ixon ixoff").

-Greg
----------

4、>> one has to wonder about the problem to be solved if */5 is so much

better
>> than an explicit list :-)
>
> Could not agree more.
>
> It would sure need a *lot* of cron jobs to be run to make the time
> saved by having */5 worth the effort of implementing it. Couple that,
> with the ease of duplicating lines in a text editor ("yy p" in vi) and
> it is hard to see any justification for it.

Actually, it is not as worthless a feature as someone may guess by
reading what you wrote. Often, any way to present information in a
consice, compact manner is nicer than having to go through a huge list.

When you see something like this in a crontab entry:

*/3 * * * * /bin/foo

you can tell immediatelly that this cron job runs every 3 minutes.

It's not the same with something like:

0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /bin/foo

because then you have to parse the long list and make sure all the
multiples of 3 are there, not to mention that you have to 'guess' that
the real reason for listing all these numbers is to get a mod 3 effect.

The explicit list offers much more flexibility though, because you are
not limited to minutes that have a zero (mod N) value, i.e. you can use
something like these lines too:

1,4,7,10,13,16,19,22,25,28,31,34,37,40,43,46,49,52,55,58 * * * * /bin/foo
2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59 * * * * /bin/foo

which allows more fine-grained control over the exact minute the job
will run.
----------
>>>Hi,
>>>I have a customer who wants cron on Solaris to have the features found
>>>on most Linux systems. The main feature is to be able to specify */5
>>>instead of 5,10,15,20,25,30,35,40,45,50,55
>>
>> There are no good cron replacements for Solaris.

>Just curious... what makes Vixie Cron unsuitable for Solaris?

It doesn't support Solaris auditing and I also don't think
it supports pam account validation and the proper account
setup (such as projects, privileges, all handled through pam
these days)

Casper
-----
Actually, it is not as worthless a feature as someone may guess by
reading what you wrote.  Often, any way to present information in a
consice, compact manner is nicer than having to go through a huge list.

True.  The thing is, there are 2^60-1 different possible combinations
for the minutes column values.  Allowing you to express 58 out of
those 2^60 possibilities[1] more concisely is not really that
earth-shattering an improvement.  Especially considering it's ugly
if the interval doesn't even divide 60.  (Would you really put
"*/13" or "*/25" for instance?)

When you see something like this in a crontab entry:

    */3 * * * * /bin/foo

you can tell immediatelly that this cron job runs every 3 minutes.

It's not the same with something like:

   0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /bin/foo

because then you have to parse the long list and make sure all the
multiples of 3 are there, not to mention that you have to 'guess' that
the real reason for listing all these numbers is to get a mod 3 effect.

Not that it's all that hard to guess after you see 0, 3, 6, and 9.

Also, personally I would make the argument that if your cron job needs
to run more than once every 10 minutes, the design of whatever system
your cron job is part of is brain-damaged.  :-)  Seriously, though,
if every 10 minutes isn't often enough for whatever it is, then whatever
it is, it should be done in response to some kind of notification rather
than by polling.  At least IMHO.  On the other hand, I guess you could
argue that computers are fast enough these days that a cruddy design
like that doesn't impact the system all that much so it doesn't matter.
But I still don't like it.  And all we are talking about here is style
rather than function, since regular cron lets you specify all 2^60-1
possible values anyway.

  - Logan

-------
[1]  It's 58 because "*/1" is equivalent to "*", which can already be
    expressed, and "*/60" is meaningless, therefore only "*/2"
    through "*/59" are new values.

All values over 30 are meaningless too.
Well, I would assume that larger values simple result in two times:
0 and the number listed.  So, for example, wouldn't "*/35" be
equivalent to "0,35"?  That's not actually meaningless; it's just
useless since the shortcut is just as long as the thing it's
supposed to be shorter than.

Come to think of it, this applies to "*/30" too, since that should
be equivalent to "0,30", which is the same length, meaning that
"*/30" offers no advantage in terms of total length.  (Although
I guess you could argue it is easier to change "*/15" to "*/30"
using a text editor than it is to change "0,15,30,45" to "0,30".)

(And it can be argued that only 2,3,4,5,6,10,12,15,20,30 are
meaningful value)

Yes, although I suppose I could see an argument for something
like "*/7":  you will have an irregular interval, but the job
will be executed nine times per hour rather then 10 or 6 times
per hour that you'd get with "*/6" or "*/10".  And "*/8" would
get you 8 times an hour.

Come to think of it, perhaps the most useful thing would be a
cron syntax that allows you to specify how many times per hour
you'd like your job to be run.  You could say 11 times per
hour, and it would then execute about every 327 seconds.

On the other hand, what I'd really prefer myself is a cron that
allows you to intentionally add random jitter.  If I have 500
desktop machines banging on some server to see if there is some
new file they need to install (or running ntpdate), I'd really
rather have cron take care of spreading out the thundering herd
automatically (by being able to say "0+/-30", meaning 0 minutes
plus or minutes 30 minutes) instead of having to pick a different
time for each machine manually.  However, that does probably
cross the border into the "hey that's neat, but is it really
worth making the operating system a complicated mess?" territory.

  - Logan

-------
>On the other hand, what I'd really prefer myself is a cron that
>allows you to intentionally add random jitter.

Yeah. We solved this with a trivial C program that just does a
short, machine specific sleep. We preface every command with a
call to the program. Eg
* 1 * * * cronsleep; /nfs/bin/dostuff

The following snippet works well on Solaris, Linux and IRIX.
long s;
s = gethostid();
s = (s & 0xff) ^ ((s & 0xff00)>>8);
(void)sleep((unsigned)s + 2);
The simpler (gethostid() & 0xff) doesn't work well with Linux systems
where gethostid returns the IP# in x86 byte order.

We based the sleep on hostid so it would be fixed for each machine,
yet typically different between machines. We wanted <5 minutes so
8 bits was convenient but you could pretty easily tweak the range.

>However, that does probably
>cross the border into the "hey that's neat, but is it really
>worth making the operating system a complicated mess?" territory.

I don't think this is worth changing the crontab(5) syntax for, but an
option to crond which does something like this wouldn't be too messy
and would have the advantage of applying to all commands.
--------
Casper's ftp://ftp.wins.uva.nl/pub/comp/solaris/auto-install/install.tar.gz
includes "rsleep.c", which sleeps some random interval from 0 to

atoi(argv[1])
seconds.

Warning: expand this tar archive within a newly created subdirectory - it
doesn't put everything in a subdirectory itself.

The notion is that you'd stack the commands, i.e.

0 0 * * * /opt/local/bin/rsleep 600;/opt/local/sbin/server_intense_command

That was so one could set up auto-patching on a large scale from an NFS
mounted patch repository and not clobber the NFS server, but it might be
useful for similar situations too. (in this no-thought example I was
assuming /opt/local was _not_ itself NFS mounted...)
--------
one has to wonder about the problem to be solved if */5 is so much better
than an explicit list :-)

The root problem is that people don't like things that are unfamiliar,
and they tend to think that if something doesn't work like what they're
accustomed to, then it is therefore bad.  Sorta like how in the transition
from SunOS 4.x to 5.x, everybody bitched and moaned about how horrible it
was to have to type "ps -ef" instead of "ps auxww".

The solution is to just agree with yourself to try the new thing for a
period of time and see if it is really bad as you think.  Most of the
time, you'll find that the annoyance factor goes away soon enough and
everything's fine and there is no need to disfigure a perfectly good
system in order to adapt it to be the way you expected rather than the
way that works best.

  - Logan

----------
Casper H.S. Dik wrote:
> There are no good cron replacements for Solaris.

IMHO, there are two issues with using cron as an industrial-strength
scheduler:

(1) Its behaviour during DST changes is loosely specified [though
thankfully, at least in S10 this is now noted in the cron(1M) man
page, so forewarned is forearmed]. (Question for the cognoscenti:
how does cron behave around leap seconds, such as the one we
had just this past week?)

(2) There is a tendency to write the jobs to be executed in a fashion
that presumes they actually get executed when they are scheduled.
But this can fail (say, because the machine is down at that
specific time), so particular invocations can be completely
skipped. This can lead to downstream resource problems (e.g.,
if an expected disk purge didn't happen on time).

Any job which is subject to problems with (2) has to be augmented
with some other invocation mechanism, and that mechanism has to
be planted so it runs at boot time and makes up for any loss of time
while the machine was down. Though I don't have a suggested design
for it, I believe this capability should be folded into cron. Not
having it is like having a language design that includes no
initialization condition on a for loop. In that context, it sounds
absurdly silly, but somehow we all put up with it in a cron context.

.
----------

5、> I have a couple of follow-up questions to my original post. I'm
> testing UFS snapshots in order to use them as a part of a
> backup/restore scheme. The servers are running DiskSuite/SVM and have
> all of the file systems (including /) mirrored. After using ufsdump to
> make a backup from a snapshot copy of the file systems, and saving a
> copy of my metadb device entries using "dd" (with a 2048k block size),
> I find that I can only restore successfully from the backups if I do a
> ufsrestore to both submirrors of a mirrored device. For example, if /
> is mounted on /dev/md/d0 and d0 is made up of submirrors d1 and d2, I
> must restore the / file system to both of the disk partitions that make
> up d1 and d2 respectively. If I only restore to the first submirror,
> and try to boot up, I get a lot of file system related errors (missing
> inodes, etc.) and the system fails to boot. I'm assuming it's
> happening because DiskSuite reads from both submirrors and fails to
> find valid data on the second submirror,

Correct, after synchronizing at metattach time, SDS/SVM will assume that
they will remain in sync. It will never "resync" them again unless you
detatch/reattach. Only writes through the mirror device (d0) are
properly handled. By ufsrestoring to one of the subdisks, you're
breaking the contract.

> but I'm wondering if others
> have run into this problem? I may have just misread the documentation
> again, but I've not found anything that indicates why this is
> happening.

That's how mirrors work. You're not allowed to touch one side behind
its back.

I'd be more prone to restore to a disk, remove any SDS stuff from
/etc/system and /etc/vfstab and recreate it from scratch on the target.
I suppose restoring the raw replicas works in some cases, but I wouldn't
trust it. It may be recording paths and/or disk IDs that will not be
the same on the target system.
-------
> > inodes, etc.) and the system fails to boot. I'm assuming it's
> > happening because DiskSuite reads from both submirrors and fails to
> > find valid data on the second submirror,
>
> Correct, after synchronizing at metattach time, SDS/SVM will assume that
> they will remain in sync. It will never "resync" them again unless you
> detatch/reattach. Only writes through the mirror device (d0) are
> properly handled. By ufsrestoring to one of the subdisks, you're
> breaking the contract.

Yep. The correct solution is to make a metadetach.

But Carolyn I don't understand if you want to restore the whole system to a
new set of disks or doing a restore from tape for recovery. Because if your
system have mirroring/submirroring active, it's only need to repair the
faulted disk and then reattach it (on new hardware disk are hot-swapable).

If you want to have a "safe" backup, dump the metaDB with "dd" and
submirroring of each filesystem you want (after doing a "metaoffline" of
each, for have it consistent). When need to restore, rememeber to follow
that simple step: rebuild the metadb, rebuild the configuration of DiskSuite
(mirroring and sub-mirroring) and make active, restore on mirror slice. This
steps in single-user mode from CD-ROM.

Hope this help.

--------
> The idea is to have a backup/recovery scenario that can be used to
> fully restore a system from scratch. I support development, test, and
> production environments, so whichever method is used needs to be
> flexible enough for use in all environments. We might have to do a
> full restore for disaster recovery of a production system, or simply to
> rebuild or clone boxes for development or testing. We're trying to get
> away from tapes and move to primarily disk-based backups (using tapes
> for offsite storage).

OK. Hope that responses are useful for you. I'm on duty on same job and we
have some script developed for doing backup or clone systems.

One steps used on that scripts are implememted what I explained on my
previous message. Our principal requirement is to backup systems for faster
repair (as a clone), but also sometime we clone system somewhere for testing
purpose or pre-production sites. I can provide more detail how it work.

Cesare

------
> I may be missing something here, but why not just restore directly to
> the d0 mirror?
>
> Or just restore to one and then mirror it afterwards.

Or restore on one-submirror while other was detached and reattach at the
end. Or restore on one submirror and then make a copy with dd utility to
other (this last option was used by myself on scripts, this is more faster
then Disksuite resync but need to be done on single-usermode where
sub-mirroring are on maintenance state).

Cesare
-------

7、use newfs -T option while creating UFS filesystem ,
else you will not be able to grow beyond 1 TB.

Check man newfs with TB support, check for option -T

man newfs

8、Patch Installation w/ JASS
(01/05/2006)

1. Download the necessary patches from
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access

2. Decompress the patches and copy to /opt/SUNWjass/Patches

Note: unzip with the -q option. For more information, see the man
pages.

3. Create a finish script for the patch/patches that needs to be added

Example:

#cd /opt/SUNWjass/Finish
#touch x-patchadd.fin
#vi x-patchadd.fin

x-patchadd.fin script:

#!/bin/sh

add_patch 111722-04

add_patch 113471-08

add_patch 115675-01

Note: add_patch is a functions within JASS, which is used to add
Solaris OS patches to the system (1).

6. Edit /opt/SUNWjass/Drivers/x-config.driver and add x-patchadd.fin
script to the driver file.

Example of x-config.driver with x-patchadd.fin script:

# more x-config.driver
#!/bin/sh
#
# Copyright (c) 2000-2002 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)config.driver 3.2 02/08/30 SMI"
#
# The purpose of this script is to perform some basic system
# configuration. This section does not necessarily perform
# security functions (perhaps with the exception of the
# installation of patches). This driver can be used as a
# template for other general system administration functions.

DIR="`/bin/dirname $0`"
export DIR

.. ${DIR}/driver.init

JASS_FILES="
/.cshrc
/.profile
"

# Note: install-recommended-patches.fin is generally always the first
# Finish script to run as it establishes the baseline system that
# will be hardened. Since these clusters contain security patches,
# it is important that they be installed before hardening the
# system.

JASS_SCRIPTS="
print-jass-environment.fin
install-recommended-patches.fin
install-jass.fin
# install-openssh.fin
set-root-password.fin
set-term-type.fin
x-patchadd.fin
"

.. ${DIR}/driver.run

7. Backup critical files by renaming them (vfstab to
backup.vfstab.date)

a. /opt/SUNWjass/bin/jass-check-sum: This command indicates which
files were changed since the last hardening run (2).

Example:

# ./jass-check-sum

Checking for file signature conflicts associated with Toolkit run:
20051130135907

File Name Saved CkSum Current
CkSum
-----------------------------------------------------------------------------

-------------------
/etc/logadm.conf 2362963540:1042
1539921394:1131
/etc/vfstab 3049598766:587
2494242351:1031
/etc/passwd 1264154811:361
3250020763:418
/etc/ssh/sshd_config 483895098:5118
2629678587:5120
/etc/shadow 256099546:258
3837770651:277
/etc/syslog.conf 258726615:480
3724897944:644

8. Un-harden the Solaris system.

a. To un-harden a Solaris system with out changing any existing
configuration, use the -k option.

Example:

#cd /opt/SUNWjass/bin
#./jass-execute -u -k -o ../undo.out.20060105.txt

b. To un-harden a Solaris system and to change everything since the
last hardening run, follow the example below.

Example:

#cd /opt/SUNWjass/bin
#./jass-execute -u -b -o ../undo.out.date.txt

9. Once the undo/un-hardening process has completed, do a boot -r.

Example:

#shutdown -y -g0 -i0
#ok boot -r

10. If the -k option was used, check if the existing
configuration/installation has changed and take the appropriate action.

11. Re-harden the Solaris system w/ JASS.

Note: Check patch requirements if it needs to be installed in single
user mode. One can go to
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access for
more information on specific patches.

Example:

a. #init s (boot in to single user mode)
b. You will be prompted for the root password. Enter the root
password.
c. #cd /opt/SUNWjass/bin
d. #./jass-execute -d ../Drivers/xt-secure.driver -o ../out.date.txt
e. Once the hardening run completes, do a boot -r

12. Check if the patches installed successfully

Example:

# patchadd -p | grep 113471-08
Patch: 113471-08 Obsoletes: 115484-01 Requires: Incompatibles:
Packages: SUNWcpcu SUNWcsu SUNWcsxu SUNWesu SUNWesxu SUNWmdb SUNWrmwbu
SUNWscpu SUNWtnfc SUNWtoo SUNWtoox

YOU HAVE SUCCESSFULLY INSTALLED THE PATCH!!!

Sources:

1. Solaris Security Toolkit 4.1 Reference Manual. "Framework
Functions." Page 24
2. Solaris Security Toolkit 4.1 Reference Manual. "Framework
Functions." Page 176

Additional Sources:

1. Solaris Security Toolkit 4.1 Administration Guide. "Understanding
the Software Components." Page 4
2. Solaris Security Toolkit 4.1 Administration Guide. "Installing the
Software." Page 103
3. Solaris Security Toolkit 4.1 Administration Guide. "Installing and
Executing the Software." Page 47

9、> Booting fsck provides very little control of the fsck command.

What control do you want? You can always do 'fsck -n' on a live
filesystem because it won't do anything behind the mount point's back.
If the fsck at boot time fails (or runs into serious issues), it will
fail and drop you at a prompt where you can run it yourself.

The command itself is used as part of the checkfs() function defined in
/sbin/rcS. I suppose you could modify that if you wanted to (although I
get a bit nervous modifying things that run before a single-user
prompt).

I'd recommend changing the ufs case line if you went there.

ufs) foptions="-o p"

> Thanks goodness we use Unix where you can actually do real

administration...
> but thats another story...

I'm not sure what you mean by that. Don't fsck a read-write mounted
filesystem (and expect it to do something good).

If you really want to, do a 'boot -b' and you'll stop the boot before
the read-write mounts have occurred. Depending on how your system is
set up (especially on whether /usr is a separate filesystem), you should
be able to fsck anything that you want.

It might be easier to just boot from CD and do it, though.

--------
>> What control do you want? You can always do 'fsck -n' on a live
>> filesystem because it won't do anything behind the mount point's back.
>> If the fsck at boot time fails (or runs into serious issues), it will
>> fail and drop you at a prompt where you can run it yourself.

> Full control. fsck -n won't do what I want. If fsck has a problem at boot,
> it will determine if the problem is serious enough to warrant stopping. It
> does have problems and is not dropping me out because it is not serious
> enough to prevent mounting.

I guess I missed that you were still having problems. What problems are
happening that the boot fsck isn't picking up?

>> The command itself is used as part of the checkfs() function defined in
>> /sbin/rcS. I suppose you could modify that if you wanted to (although I
>> get a bit nervous modifying things that run before a single-user
>> prompt).

> I can't find any function checkfs() in /sbin/rcS.
> Modifying these scripts doesn't sound like a "correct method" for what I
> want to do..

>> ufs) foptions="-o p"

> Doesn't sound like a great idea, but where is it anyway?

Sorry. That was the pre-10 location. For 10, it's in
/lib/svc/share/fs_include.sh

>> If you really want to, do a 'boot -b' and you'll stop the boot before

> I can't find this option either.

Hmm. I didn't realize that was gone from 10 also. There's no milestone
which corresponds to the old -b stopping point. I'll have to see how
that might be possible...

-------
new to Sol 10 and can't figure out how to umount /var for a fsck due to
svc.startd process.

With the coming of SMF this is becoming nearly impossible since the

svc.startd
process logs directly to /var/svc/logs and as far as I know you can't kill

this
process without performing a reboot.

So the only option would be a rescue disk or a reboot.
What about "lockfs -fw /var ; fsck -n /var ; lockfs -u /var"?

It seems like there is at least a chance it will work, although if you
actually need to make a change the filesystem, you can't do that
while it's mounted.  (But at least you can make the system stop writing
to it.)

If you try this, be forewarned that there is serious potential for
deadlocking the system if you go this route!  (Trust me...)

  - Logan
.
--------
>> With the coming of SMF this is becoming nearly impossible since the
>> svc.startd process logs directly to /var/svc/logs and as far as I know you
>> can't kill this process without performing a reboot.
>>
>> So the only option would be a rescue disk or a reboot.

> What about "lockfs -fw /var ; fsck -n /var ; lockfs -u /var"?

That or a "mount -o remount,ro /var" are possible candidates to prevent
filesystem access while the fsck can do its work. I think it might be able to
repair things because fsck will access the device and not so much the
filesystem.

However, I have no idea how svc.startd would respond to all this which is why

I
wouldn't recommend doing this. After all; when it detects an error it'll
restart with all possible consequences.

Interesting idea to give it a try in the weekend, but I don't think its a

good
idea for live systems ;)

-------
>That or a "mount -o remount,ro /var" are possible candidates to prevent
>filesystem access while the fsck can do its work. I think it might be able

to
>repair things because fsck will access the device and not so much the
>filesystem.

"ro" remounts do not work.

You can always boot with -mmilestone=none and you'll be left with
only "/".

Casper
----

8、> > I've been searching for third party TFTP software for SPARC running
> > Solaris 9. Can anyone suggest one or point me in the right direction?
>
> Linux machines run tftp servers. I don't know if it'll compile on
> solaris out of the box, but it shouldn't be too hard.

tftp-ha (http://freshmeat.net/projects/tftp-hpa/) works just fine on
Solaris.

- Michael
--------

9、> I was given a V440 with 4 x 72G disks to play with (and expected to go
> into production ASAP of course). So I mirrored two of the disks for
> system stuff. Didn't really know what to do with the other two 72G
> disks (I not very smart). Actually, I think they are a waste of money,
> as I'm already attached to the SAN for the heavy hogs (developers and
> DB's).

> Now I want to expand the / volume, since opt is already filling up its
> 10G.

> Does anyone know any easy way to do this? I'm used to good ol'
> Veritas.

How would you do this in VxVM? It's not much different, just a bit more
manual.

> The following does not make sense to me. My notes are in ( ).

> "Existing volumes can be enlarged by adding additional slices. (I only
> have a few slices left, why use one to expand a existing slice?)

This is the default method for general (non boot) volumes. It's easier
to add a new slice because SVM offers no facility for moving data. If
data exists immediately after the one you want to expand, it cannot do
so.

> After
> you grow your volume, you will probably want to grow the file system
> that uses that volume by using the growfs command. Although growing
> file systems does not result in data loss, it's still a good idea to
> back up your file system before attempting configuration changes.
> Volumes can be expanded but cannot be shrunk without destroying the
> volume and creating a new one."

growfs is not supported for the root filesystem while booted from it.

> "You can use concatenated volumes to expand existing file systems
> without needing to reboot your computer.

Only true for non boot-critical filesystems. Root cannot be a
concatenated (or stripe or raid5) volume.

You have several choices.

*) Old school
Format a disk (either one you're not using, or drop one of the mirrors)
to the way you want. ufsdump/ufsrestore data to the new disk into the
locations you want. Put a boot block on there, set the /etc/vfstab,
clear the rootvol in /etc/system and boot from it. After verifying it
works, redo SVM and mirroring.

*) Use the mirrors
Drop one of the mirrors. Repartition the way you want (with all
filesystems being the same or larger as the original). Mirror. Repeat
on original. Now you've got everything in place, but the filesystem
hasn't been enlarged. You can run 'growfs' on the non-root
filesystems. Boot from install media so that the on-disk SVM is found
and filesystems are mounted. Run growfs on the root filesystem.

*) Use Live Upgrade.
You can use LU to copy the system over to one of the unused disks.
Partition it as you want, then set up the environment. When done, it's
a quick reboot into the new environment.

Having the extra 2 disks is really cool with LU. You can keep the
system mirrored *and* have a separate BE. Also, you can have replicas
on more than 2 disks.
----------
> On my two unused disks, looking at the partition output posted above,
> why do they both show a /usr partition occupying the entire disk
> (blocks 52 - 14086)? I have not touched those disks yet...confusing.

It's just a default partition layout for a SUN label. You can ignore it
or I'd just remove it. There won't be any data there. You'd see
something similar even if the disk couldn't be read.

> By the way, I used to use the Veritas GUI (hard to admit).

The GUI is better at displaying some layouts. It takes a bit more time
to read through several pages of 'vxprint' when they get complex.

VxVM can make much of expanding/moving filesystems and volumes *much*
easier than in SDS/SVM, but the root filesystem is special and it's not
much easier in VxVM. You have to ensure that root is always a
single-disk, contiguous, cylinder-aligned volume. Because of that, the
normal methods for moving volumes around (by moving them in pieces)
can't be used.

Easist for doing this within VxVM (if it was encapsulated and you didn't
want to de-encap), would be to mirror to another disk, lose the old
mirror, enlarge, repeat with any other filesystems/volumes, then mirror
back. Pretty much the same in SDS/SVM, except you set the sizes
explicitly in 'format' before starting the first mirror.

----

9、> "unassigned" even though it is actually the /mycompany/usr partition as
> shown in df -k?

> This is a new Solaris 10 install.

> format of c1t0d0:
> Part Tag Flag Cylinders Size Blocks
> 0 root wm 1649 - 3661 9.77GB (2013/0/0)
> 20484288
> 1 swap wu 0 - 1648 8.00GB (1649/0/0)
> 16780224
> 2 backup wm 0 - 14086 68.35GB (14087/0/0)
> 143349312
> 3 var wm 3662 - 5272 7.82GB (1611/0/0)
> 16393536
> 4 unassigned wm 5273 - 7285 9.77GB (2013/0/0)
> 20484288

Because the 'Tag' field is an ancient concept, unused by almost
everything today, but it is still shown by 'format' and 'prtvtoc'. It
is a 4 byte field that can only represent a limited number of items.
Only a few OS filesystems will have a matching tag name. You have to
pick something else (like 'unassigned') for any others.

You can see the possibilities in /usr/include/sys/vtoc.h.

As long as you don't use 'root', the system won't care which one you
pick.

----------
 You can see the possibilities in /usr/include/sys/vtoc.h.

> As long as you don't use 'root', the system won't care which one you
> pick.

And for clarification since I got some email, the running system almost
certainly wouldn't care at all even if you did use root. I only know of
two things that actually care about the contents of the 'Tag' fields.

1) Suninstall upgrades
When the installer runs, it looks at the local disks for 'root' tagged
slices and sees if they are a real root filesystem, opens any
/etc/vfstab in them and determines if that describes an upgradeable
system. If you have multiple 'root' tagged slices, I think it gets
confused and refuses to upgrade. That's what I was referring to with my
last statement. I have run dual-OS SPARC systems with separate root
slices (each 'root' tagged) with no issues.

2) Veritas Volume Manager
All veritas initialized disks of type 'sliced' and a VTOC label use tags
'14' and '15' to represent the private and public regions (easier to see
in 'prtvtoc' than in 'format'). If those tags aren't present, VxVM will
not automatically find and recognize the disk as a valid vxdisk.

--

10、> > What kinds of tools do you use to manage your system personality?
>
> I consider what you refer to as "system personality" to be more akin
> to a system migration.

You're right that it's a kind of migration I have in mind, but it's
more general than that. It seems to me that I want a complete copy
of