Why do the new Solaris 10 Services need a binary config file that gets rewritten on system boot? My impression is that they are similar to inited, but why the binary config file? What was the thought behind this design decision?
In article <m3mzv7bjer....@linux.local>, Mike Cox <mikecoxli...@yahoo.com> wrote:
>Why do the new Solaris 10 Services need a binary config file that gets >rewritten on system boot? My impression is that they are similar to >inited, but why the binary config file? What was the thought behind >this design decision?
Try to read the man pages and check Solaris 10 until you know enough to be able to ask the question in a way that other people understand your problem.
Joerg Schilling wrote: > In article <m3mzv7bjer....@linux.local>, > Mike Cox <mikecoxli...@yahoo.com> wrote: > >Why do the new Solaris 10 Services need a binary config file that gets > >rewritten on system boot? My impression is that they are similar to > >inited, but why the binary config file? What was the thought behind > >this design decision?
> Try to read the man pages and check Solaris 10 until you know > enough to be able to ask the question in a way that other people > understand your problem.
: In article <m3mzv7bjer....@linux.local>, : Mike Cox <mikecoxli...@yahoo.com> wrote: : >Why do the new Solaris 10 Services need a binary config file that gets : >rewritten on system boot? My impression is that they are similar to : >inited, but why the binary config file? What was the thought behind : >this design decision? : : Try to read the man pages and check Solaris 10 until you know : enough to be able to ask the question in a way that other people : understand your problem.
I think Mike is tring to veryify if some of my comments about the svc junk are true. The point I think he may be tring to veryify is the fact that if you mess with one of the binary files, you can run things in such a way that a sysadmin can't find out out whats being run.
My take on the svc stuff is that its windows registry for unix. And there is no way I'm running that junk on a production system. It was a great idea but I'm not putting it into production until the current system is refactor/rewritten. I'll stick with Solaris 9 or wait till 11. I'm not going to be a test crack site for NIS^H^H^Hsvc.
"palowoda" <palow...@fiver.net> writes: > Joerg Schilling wrote: >> In article <m3mzv7bjer....@linux.local>, >> Mike Cox <mikecoxli...@yahoo.com> wrote: >> >Why do the new Solaris 10 Services need a binary config file that > gets >> >rewritten on system boot? My impression is that they are similar to >> >inited, but why the binary config file? What was the thought behind >> >this design decision?
>> Try to read the man pages and check Solaris 10 until you know >> enough to be able to ask the question in a way that other people >> understand your problem.
The Internet services daemon, inetd(1M), has been rewritten as part of SMF. It stores all of its configuration data in the SMF database, rather than /etc/inet/inetd.conf, allowing the SMF tools to be used to control and observe inetd-based services.
is a good explanation of why a binary format is required or haven't I read far enough?
Dan Espen <dan...@spam.mk.telcordia.com> wrote: > So you are saying this: > The Internet services daemon, inetd(1M), has been rewritten as part of > SMF. It stores all of its configuration data in the SMF database, > rather than /etc/inet/inetd.conf, allowing the SMF tools to be used to > control and observe inetd-based services. > is a good explanation of why a binary format is required > or haven't I read far enough?
Perhaps he's still under NDA and is not obliged to give useful information.
Thomas Dickey <dic...@saltmine.radix.net> writes: > Dan Espen <dan...@spam.mk.telcordia.com> wrote:
>> So you are saying this:
>> The Internet services daemon, inetd(1M), has been rewritten as part of >> SMF. It stores all of its configuration data in the SMF database, >> rather than /etc/inet/inetd.conf, allowing the SMF tools to be used to >> control and observe inetd-based services.
>> is a good explanation of why a binary format is required >> or haven't I read far enough?
> Perhaps he's still under NDA and is not obliged to give useful information.
Funny, they say it's difficult to communicate humor or sarcasm on Usenet.
Tim Hogard wrote: > Joerg Schilling (j...@cs.tu-berlin.de) wrote: > : In article <m3mzv7bjer....@linux.local>, > : Mike Cox <mikecoxli...@yahoo.com> wrote: > : >Why do the new Solaris 10 Services need a binary config file that gets > : >rewritten on system boot? My impression is that they are similar to > : >inited, but why the binary config file? What was the thought behind > : >this design decision? > : > : Try to read the man pages and check Solaris 10 until you know > : enough to be able to ask the question in a way that other people > : understand your problem.
> I think Mike is tring to veryify if some of my comments about the svc junk > are true. The point I think he may be tring to veryify is the fact that > if you mess with one of the binary files, you can run things in such > a way that a sysadmin can't find out out whats being run.
> My take on the svc stuff is that its windows registry for unix. > And there is no way I'm running that junk on a production system. > It was a great idea but I'm not putting it into production until > the current system is refactor/rewritten. > I'll stick with Solaris 9 or wait till 11. I'm not going > to be a test crack site for NIS^H^H^Hsvc.
On Tue, 18 Jan 2005, Dan Espen wrote: > "palowoda" <palow...@fiver.net> writes:
> > Joerg Schilling wrote: > >> In article <m3mzv7bjer....@linux.local>, > >> Mike Cox <mikecoxli...@yahoo.com> wrote: > >> >Why do the new Solaris 10 Services need a binary config file that > > gets > >> >rewritten on system boot? My impression is that they are similar to > >> >inited, but why the binary config file? What was the thought behind > >> >this design decision? [...] > So you are saying this:
> The Internet services daemon, inetd(1M), has been rewritten as part of > SMF. It stores all of its configuration data in the SMF database, > rather than /etc/inet/inetd.conf, allowing the SMF tools to be used to > control and observe inetd-based services.
> is a good explanation of why a binary format is required > or haven't I read far enough?
I don't know either. Maybe we can guess:
It's an SQLite database file (strings).
Since SMF allows services to be executed in parallel during boot across many CPUs, I imagine one problem was the locking of this database (assuming we need to write to it often. meeting dependancies?). Perhaps making it an SQLite file solved that problem - as it may already implement that feature in its library calls.
It's also put the data in a format that is easy for the system to process (quite possibly outright faster than text based), and easier to extend.
... I've probably missed a man page that explains it neatly somewhere!...
: Which is the whole reason it has 'beta' written all over it
Back when I took engineering classes, Beta Testing had a specific meaning which involved testing done by people that represented the general public users of the product. It didn't mean a prototype.
thog...@abnormal.com (Tim Hogard) writes: > Joerg Schilling (j...@cs.tu-berlin.de) wrote: > : In article <m3mzv7bjer....@linux.local>, > : Mike Cox <mikecoxli...@yahoo.com> wrote: > : >Why do the new Solaris 10 Services need a binary config file that gets > : >rewritten on system boot? My impression is that they are similar to > : >inited, but why the binary config file? What was the thought behind > : >this design decision? > : > : Try to read the man pages and check Solaris 10 until you know > : enough to be able to ask the question in a way that other people > : understand your problem.
> I think Mike is tring to veryify if some of my comments about the svc junk > are true. The point I think he may be tring to veryify is the fact that > if you mess with one of the binary files, you can run things in such > a way that a sysadmin can't find out out whats being run.
I don't know where you got this idea. SMF uses fork(2) and exec(2) like anything else.
Nothing that is started via smf is invisible to ps, if that's what you mean. In fact, in many cases it's easier to keep track of which processes belong to which services:
> My take on the svc stuff is that its windows registry for unix.
This statement conveys a misunderstanding of the windows registry, the smf database, or both.
> And there is no way I'm running that junk on a production system. > It was a great idea but I'm not putting it into production until > the current system is refactor/rewritten.
It was a great idea but I'm not using it?
> I'll stick with Solaris 9 or wait till 11. I'm not going > to be a test crack site for NIS^H^H^Hsvc.
This sounds like paranoia springing from an incomplete understanding.
: I don't know where you got this idea. SMF uses fork(2) and exec(2) like : anything else. : : Nothing that is started via smf is invisible to ps, if that's what you : mean. In fact, in many cases it's easier to keep track of which : processes belong to which services: I'm aware of that. What can be done is things can be hidden in the sqlite file in such a way that the tools don't list them but they will get run. If the application knows how to hide its self (argv[0], rm its binary or other tricks), it will be a real pain to figure out what started the process and that assumes its still running and isn't triggered ina complex way.
: > My take on the svc stuff is that its windows registry for unix. : : This statement conveys a misunderstanding of the windows registry, the : smf database, or both. They both are script kiddies dreams.
: > And there is no way I'm running that junk on a production system. : > It was a great idea but I'm not putting it into production until : > the current system is refactor/rewritten. : : It was a great idea but I'm not using it? Not if its implementation is wrong.
: > I'll stick with Solaris 9 or wait till 11. I'm not going : > to be a test crack site for NIS^H^H^Hsvc. : : This sounds like paranoia springing from an incomplete understanding. The more I understand it, the more I know I want to avoid it. I've got one report of someone else thats taken a binary editor to the file and come up with different results than what I did. Sun needs to fix this soon. If they aren't going to dump the binary file: 1) write the binary file only the xml source files get changed. 2) save the on/off states in a different file 3) save the timestamps elsewhere (maybe in the same file as #2) 4) do sanity checks on the binary file. This means account for every byte in the file and trace it back to its source and make sure that there are no overlaps.
I don't know how others run their systems, but I like to be able to do checksums on all binary files that are critical and I want to be able to check them aginst my off site checksums. I don't like them to change very often. If it lives in /etc/ I should be able to make the whole thing read only without breaking anything.
|
