In putting together PSARC/2009/332 and looking at the
changes required to libraries and installation, I'm
being given a choice about whether or not the project
number for "svc.inetd" is important.
The man page for project(4) says this:
projid The project's unique numerical ID (PROJID)
within the system. The maximum value of the
projid field is MAXPROJID. Project IDs below
100 are reserved for the use of the operating
system.
I suspect that this is a carryover from usernames, uids
and /etc/passwd in that so far as I can tell, the project
id's are not important in the same way that a uid is.
Whilst it is convenient to have project numbers be the
same everywhere, there's no operational requirement.
Unlike files, where the uid is a property that can be
saved/restored/copied, the project id for "user.root"
could be different on every system and there would be
no interoperability or behavioural problems.
The only exception I can think of might be a cluster,
where processes can migrate between nodes.
There are a couple of reasons for this public musing:
1) we already have almost 300 SMF services and if were
to define a project for each one, we would blow the
"100" limit mentioned in project(4). We could take
this on and have the limit raised to 1000, but I'm
not sure that is necessary...
2) As part of the work for PSARC/2009/332, I'm putting
together a "i.project" file to add the "svc.inetd"
project to existing /etc/project files when people
do an upgrade. The obvious thing to do is to add it
to the file in a way that makes it identical to the
/etc/project that gets committed. But there is no
operational need that I can see for that to happen.
So, what I would like to do is the following:
a) ship /etc/project to new systems with the project
number fixed as per what's in ON;
b) remove the documented limit of 100 from project(4);
c) write the i.project file to "allocate the next free
project number" to "svc.inetd" (or any later projects)
rather than used a fixed number. Actually, if
projadd(1M) understood "-R /a", /usr/sbin/projadd is
there when doing an install, it becomes very easy.
Comments?
Darren
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
