QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
|
< Cheatsheet for configuring the networking in Solaris 11 | How to show off live migration with a SPARC system? >
Cheatsheet for configuring a new nodename in Solaris 11Saturday, March 3. 2012Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Does this include all the host/nodename settings? I am thinking of mailname, smtp hostname, uname/ypname, /etc/hostname, dhcp, dns registrations and similiar stuff?
Do you know what that means? Everytime I want to change a hostname, I have to google for that line because I am not able to remember a line like
svccfg -s svc:/system/identity:node setprop config/nodename = "fuchikoma" for a not even monthly occuring task ^-^ Nice GitS reference btw.
Thanks Joerg!
On a side note, I have no idea why Oracle decided to use SMF for all of this. Solaris now has a registry, just like Windows. Seems like a bad evolution to me. UNIX prides itself on using well known files where we may make quick changes and also derive data. This does nothing to solve any atomicity problems, nor do I think this is beyond a solution looking for a problem. I am normally open minded about OS changes and I think the switch away from ifconfig(1M) is a good thing. So don't get me wrong. But interfacing all of this stuff with SMF which in turn writes out a file is just crazy. In previous releases to Solaris I have always ended up loving the changes even though they fundamentally alter the way I have to work. ZFS, SMF are just to name a few. SMF is overly complicated in many ways and I hate XML, but it does solve real problems. But extending a Service Management Framework (which is really what this software was intended to do) to become a registry for Solaris is not a welcome change. This kind of stuff makes AIX and Linux seem adherent to UNIX principles.
As i already wrote, there are good reasons to do it. Like "when get the change active"? But as well "What services are dependent on the change of a certain piece of information?" The writeout of the file are most often not because the respective service need it, but because there are programs that want to see this file that are outside of the file.
And in regard of Linux? Well, i'm really interested how the "poetteringification" of linux will go forward. The Linux of the future won't have much to do with the the current Linux. And AIX? Most of the time i just hear "Not without my SMIT".
My final touch on the last post perhaps suggests that I'm a troll. Don't want you to think that and I admit that it was a bit out of character for me. First off I am no proponent of AIX or Linux. In fact I don't like either of them. I can't stand Linux because it deviates too much from UNIX and GNU tools piss me off most of the time. How about changing the way directory listings are collated with some stupid LANG variable or the ever growing swamp of dash-dash-very-verbosely-explained-option pragma.
So whenever I see Solaris "evolving" in ways that there was no need to evolve it, its becoming a headache. Not only does Oracle change the way things are done (which I am less concerned with) but it seems as if this wasn't thought through very well. At least, there should be ample warning prior to release that this will indeed happen. Again, nobody has given me a good reason to do this other than its a nice-to-have. SMF is not without complexity and changes like integrating a parser to generate a file which is a known quantity in and of itself is not only adding moving parts, but at this point Oracle needs to listen to its users and see whether this is indeed a welcome change. I don't know anybody who thinks that Solaris 11 is as nice as it could have been, primarily because of the needless complexity introduced. I'm saying this in an effort to be forthcoming and constructively criticizing, not a jerk. -Alex
Comparing SMF to AIX's SMIT is like apples and oranges. AIX needs SMIT because many configuration files and options are in so non-standard places that you would go crazy trying to remember everything. SMIT is more or less an automated cheat-sheet. Solaris has preserved SVR5 conventions for decades, every Unix admin knows where to find what info and how to change it.
Oracle seems to aim with SMF at the novice admin who doesn't want to learn about config files and have every option in one place/tool - while simultaneously slapping the face of every old and experienced admin who is used to editing config files instead of xml repositories or using interactive questionnaires. IMHO, this trend has been set largely by Linux (yast comes to mind..) aiming for the novice desktop user. It seems like Oracle has a weird impression of the Solaris user base / target audience. (Only a decade ago there was a statement from Sun that "real admins don't want interactive config tools" when people asked why they killed the 'admintool' and 'metatool' GUI from Solaris 9. Especially the later one could have been nicely extended for ZFS...)
All the reasons for use smf and use XML, are for make more simplers the programming of the Solaris utilities o upgrade/installer programs
They aren't for the sake to make more easy the life of the Solaris administrator, that I think that it is the most important. They are done for the sake of the programming the Solaris. At the end, it will be a GUI (smit/SAM) for Solaris There is other alternatives to the SMF services as the NetBSD rc system: http://www.netbsd.org/docs/guide/en/chap-rc.html I think if the configuration isn't done in file texts it is "less UNIX". I propose to create a facebook called "Oracle please drop SMF". Do you suggest other name? I think that is a lost battle, but I prefer trying it that see my prefer OS to go in a rotten state. I think that is sad, that to simple tasks as change the name server and resolv.conf need two articles in c0t0d0s0 by its complexity.
I've come to love SMF. It's over engineered in that it requires XML and a bunch of stuff like that, but coupled with contracts (which is a very important in-kernel underpinning of SMF) it is superior to anything else out there purporting to track PIDs. Upstart for Linux was supposed to be an SMF workalike but even though its configuration stanza is much easier to make sense of, its not able to do anything beyond trying to remember a PID as opposed to knowing exactly which PID a service is running under. But as far as I'm concerned, net result is SMF is good.
But I'm disturbed with the amount of stuff that will go into SMF and the fact that we're forced to use it. Granted, being forced to do something in a particular way can be a Good Thing, but in this case Solaris is starting to use SMF as a Windows-like registry. The problem is compounded with the fact that files which were previously administrator maintained are now generated from SMF, so the net result is mainly more moving parts -- more that can go wrong.
SMF by itself is not a bad concept as long as it is used for what its name indicates - managing system services.
Oracle trying to make SMF a one-for-all management tool is not such a good idea IMHO. As a first step, SMF should be finalized for its primary purpose, before trying to tack on more features that have nothing to do with service control. For example, I still don't see any way in SMF to have a crashed daemon automatically restart - it drops to maintenance and that's it. This is a feature that even the 30 year old inittab concept already had.. ("respawn" option). There's not even a way for any kind of notification on service state change. SMF is simply incomplete.. tacking on new tasks now is plain featuritis.
First search in gmail about mail notification:
http://docs.oracle.com/cd/E23824_01/html/821-1451/dzhaq.html#glhtt I think that smf tries to restart the daemon several times. If it fails many times in a given interval of time, it transitions the service to maintenance. I think that smf is overenginered for a simple task of watchdog, and most of Solaris services I am not concerned about auto-restart a service (it was done by inetd most of the times), and other services as rpc.bind, inetd, sendmail, it was very dificult to crash them. For two/three problematic servers it is more easy a watchdog service. But as I see SMF lovers I will change the proposal to: Oracle please use SMF only for manage System Services
Care to make a paste bin of your manifest? I've been able to get what I think you're trying to do, to work. In essence the 'restart_on' attribute controls whether a particular condition on a dependency should trigger a restart or fall back to maintenance mode.
Or are you trying to improve service life of a buggy daemon by restarting it? -Alex
Why 'svcadm refresh' and 'svcadm restart'?
In the other post you said "it wasn't always clear to most people when a change of the configuration got active. .. By using SMF it's clear. As soon as you type in svcadm refresh." To me it seems it is still not clear with SMF. Is it with 'svcadm refresh' or 'svcadm restart'? I'm always confused. |
+1The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Comments about Ulrich Gräf
Mon, 17.06.2013 09:02
about Thank you!
Wed, 05.06.2013 16:58
additional thanx a lot for joi
ning us in vienna at Solaris d
ay !
about Lieber SPON, ...
Fri, 17.05.2013 08:09
Du solltest auch noch JS ausch
alten, dann bekommst du auch n
icht diese lustige Nachricht ü
ber AdBlocker
Buttons![]() This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
![]() ![]() ![]() Blog Administration |