[tao-users] Thoughts about TAO installed service names
Ken Sedgwick
I'm working on preparing the ACE+TAO packages for inclusion in Fedora.
I'm not confident that the names of the installed service binaries are
optimum yet.
The following TAO rpm packages deliver executable services:
Package Name Executable Name
------------ ---------------
tao-naming Naming_Service
tao-cosevent CosEvent_Service
tao-notify Notify_Service
tao-trading Trading_Service
tao-event Event_Service
tao-concurrency Concurrency_Service
Are these executable daemon names "distinguished" enough in a general
namespace perspective?
We can rename the binaries when they are installed. Would it
be better to name the Naming_Service something like:
tao_naming
tao_namingd
taonamingd
<something else?>
For example, when we install the idl compiler we call it tao_idl ...
Thoughts? Preferences? Other suggestions?
Ken
--
Ken Sedgwick
Bonsai Software, Inc.
http://www.bonsai.com/ken/
(510) 610-4162
ken...@bonsai.com
Public Key: http://www.bonsai.com/ken/ken.asc
GPG Fingerprint: 851E 3B07 E586 0843 9434 5CC7 4033 3B9B 3F3F 9640
Thomas Girard
thanks for bringing this topic on the list. I agree that TAO binaries
names could be more consistent.
On Sun, Mar 30, 2008 at 04:07:26PM -0700, Ken Sedgwick wrote:
> I'm working on preparing the ACE+TAO packages for inclusion in Fedora.
>
> I'm not confident that the names of the installed service binaries are
> optimum yet.
>
> The following TAO rpm packages deliver executable services:
>
> Package Name Executable Name
> ------------ ---------------
> tao-naming Naming_Service
> tao-cosevent CosEvent_Service
> tao-notify Notify_Service
> tao-trading Trading_Service
> tao-event Event_Service
> tao-concurrency Concurrency_Service
In Debian we also have:
tao-ifr IFR_Service tao_ifr
tao-ft Fault_Detector Fault_Notifier FT_ReplicationManager
tao-ftrtevent ftrt_eventservice ftrtec_{factory,gateway}_service
tao-imr ImplRepo_Service ImR_Activator tao_imr
tao-lifecycle LifeCycle_Service
tao-load LoadManager LoadMonitor
tao-log {Basic,Event,Notify,RTEvent}_Logging_Service
tao-event* CosEvent_Service
tao-scheduling Scheduling_Service Dump_Schedule
tao-time Time_Service_Server Time_Service_Clerk
> Are these executable daemon names "distinguished" enough in a general
> namespace perspective?
>
> We can rename the binaries when they are installed. Would it
> be better to name the Naming_Service something like:
>
> tao_naming
> tao_namingd
> taonamingd
> <something else?>
I would prefer tao_naming (or tao-naming to match the package name).
> For example, when we install the idl compiler we call it tao_idl ...
>
> Thoughts? Preferences? Other suggestions?
If your proposal is to prepend `tao_' to every binary name then I
approve it.
Regards,
Thomas
* tao-rtevent contains Event_Service
Johnny Willemsen
> thanks for bringing this topic on the list. I agree that TAO binaries
> names could be more consistent.
I also agree. Maybe it is better to do this in the code repository also but
that would mean some changes to all users and to all the test scripts.
Personally I am in favor of changing this now, then it can go into the x.6.4
version which will be the last beta before the x.7 release.
> If your proposal is to prepend `tao_' to every binary name then I
> approve it.
It seems multiple people are working on the packaging for different
distributions. We should prevent duplicated work, we can put helper scripts
into the repository so that you can share things. How do you want to handle
the different ACE/TAO versions? Also be aware that the autoconf support has
been improved but it is not yet at the same level as the traditional way of
compilation.
Regards,
Johnny Willemsen
Remedy IT
Postbus 101
2650 AC Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl
*** Integrated compile and test statistics see
http://scoreboard.theaceorb.nl ***
*** Commercial service and support for ACE/TAO/CIAO ***
*** See http://www.theaceorb.nl/en/support.html ***
Jules Colding
On 31/03/2008, at 01.07, Ken Sedgwick wrote:
> Greetings,
>
> I'm working on preparing the ACE+TAO packages for inclusion in Fedora.
>
> I'm not confident that the names of the installed service binaries are
> optimum yet.
>
> The following TAO rpm packages deliver executable services:
>
> Package Name Executable Name
> ------------ ---------------
> tao-naming Naming_Service
> tao-cosevent CosEvent_Service
> tao-notify Notify_Service
> tao-trading Trading_Service
> tao-event Event_Service
> tao-concurrency Concurrency_Service
>
> Are these executable daemon names "distinguished" enough in a general
> namespace perspective?
>
> We can rename the binaries when they are installed. Would it
> be better to name the Naming_Service something like:
>
> tao_naming
> tao_namingd
> taonamingd
> <something else?>
>
> For example, when we install the idl compiler we call it tao_idl ...
>
> Thoughts? Preferences? Other suggestions?
I think prefixing with "tao_" would be a good thing.
BTW - Are you building on rawhide? There is quite a few gcc warnings
that needs care and attention. They will break any clients building
with "-Werror".
BR,
jules
Johnny Willemsen
> BTW - Are you building on rawhide? There is quite a few gcc warnings
> that needs care and attention. They will break any clients building
> with "-Werror".
If someone can sponsor/contribute a build with rawhide the warnings are
visibile for everyone and people can see the status. For FC8 we only build
and test ACE, no TAO is build/tested at all. Also the scoreboard does build
with traditional way of compilation.
Johnny
Jules Colding
I'm working on getting a build up and running on rawhide (GCC 4.3.0)
this week.
--
jules
Johnny Willemsen
> >> BTW - Are you building on rawhide? There is quite a few gcc warnings
> >> that needs care and attention. They will break any clients building
> >> with "-Werror".
> >
> > If someone can sponsor/contribute a build with rawhide the warnings
> > are
> > visibile for everyone and people can see the status. For FC8 we only
> > build
> > and test ACE, no TAO is build/tested at all. Also the scoreboard
> > does build
> > with traditional way of compilation.
>
> I'm working on getting a build up and running on rawhide (GCC 4.3.0)
> this week.
Great! For all users, instructions how to setup a daily build and contribute
it to the scoreboard is documented in the TAO Programmers Guide (see
www.theaceorb.nl). With more builds we can make sure ACE/TAO build and run
out of the box on more platforms.
Regards,
Johnny
Jules Colding
On 31/03/2008, at 10.54, Johnny Willemsen wrote:
> It seems multiple people are working on the packaging for different
> distributions. We should prevent duplicated work, we can put helper
> scripts
> into the repository so that you can share things. How do you want to
> handle
> the different ACE/TAO versions? Also be aware that the autoconf
> support has
> been improved but it is not yet at the same level as the traditional
> way of
> compilation.
It can not be directly of use here, but I've managed to get the
autotool build system of Lorica to support making release binaries on
a good handful of different platforms:
*) RPMs on RHEL and Fedora
*) debs on Ubuntu
*) dmg on Mac OS X
*) ebuild on Gentoo
All it takes is a simple "./bootstrap && make distfiles". I've create
m4 macros to identify the build platform and massaged the top-level
Makefile.am into doing the right thing depending on the detected build
platform. It is easily expandable to more platforms and package
managers.
Anyone is welcome to be inspired from that work.
BR,
jules
J.T. Conklin
> thanks for bringing this topic on the list. I agree that TAO binaries
> names could be more consistent.
>
>>
>> I'm not confident that the names of the installed service binaries are
>> optimum yet.
>>
>> The following TAO rpm packages deliver executable services:
>>
>> Package Name Executable Name
>> ------------ ---------------
>> tao-naming Naming_Service
>> tao-cosevent CosEvent_Service
>> tao-notify Notify_Service
>> tao-trading Trading_Service
>> tao-event Event_Service
>> tao-concurrency Concurrency_Service
Does tao-naming also include nslist, nsadd and nsdel? For packaging,
I'd think we'd want the associated utilities in with the package, or
perhaps having a tao-naming-utils, etc. package as well if we're
trying to minimize footprint.
> In Debian we also have:
> tao-ifr IFR_Service tao_ifr
> tao-ft Fault_Detector Fault_Notifier FT_ReplicationManager
> tao-ftrtevent ftrt_eventservice ftrtec_{factory,gateway}_service
> tao-imr ImplRepo_Service ImR_Activator tao_imr
> tao-lifecycle LifeCycle_Service
> tao-load LoadManager LoadMonitor
> tao-log {Basic,Event,Notify,RTEvent}_Logging_Service
> tao-event* CosEvent_Service
> tao-scheduling Scheduling_Service Dump_Schedule
> tao-time Time_Service_Server Time_Service_Clerk
I'm suprised that you've bothered to package some of these as
installable packages, in particular the life cycle service, which
is more of an example or unit test than a real, deployable, service.
I'd tend to call the CosEvent service just plain event, or prefix
every OMG "CosFoo" service with "Cos". It's only long term users
that think of the RT TAO event service as "Event".
On the other hand, it may be better to use names inspired by the
official OMG spec, so TLS instead of log for the Telecom Log Service.
>> We can rename the binaries when they are installed. Would it
>> be better to name the Naming_Service something like:
>>
>> tao_naming
>> tao_namingd
>> taonamingd
>> <something else?>
>
> I would prefer tao_naming (or tao-naming to match the package name).
One of the first things we should look at is the catior utility, as it
already conflicts with a similar utility from another ORB (I think
OmniORB, but it might have bin MICO)
With the autoconf build's --program-prefix, --program-suffix, and
--program-transform-name options, we already have a great deal of
flexibility in renaming the installed binaries. The GNUace build
doesn't have this, but it doesn't really have an "install" mode
either. We can look to add similar transforms when/if that work
gets done/sponsored/etc.
However, if binaries are going to be renamed, I'd prefer that they be
renamed for all TAO installations, rather than just for
packaging. Otherwise documentation and online support gets more
difficult. This will be a bigger challenge, as the current names are
hard-coded many places within the sources (unit tests, etc.).
--jtc
--
J.T. Conklin
Douglas C. Schmidt
> However, if binaries are going to be renamed, I'd prefer that they
> be renamed for all TAO installations, rather than just for
> packaging. Otherwise documentation and online support gets more
> difficult. This will be a bigger challenge, as the current names are
> hard-coded many places within the sources (unit tests, etc.).
I totally agree. Once we converge on the names for the packages let's
retro fit this back into TAO.
Thanks,
Doug
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203 NET: d.sc...@vanderbilt.edu
Thomas Girard
Le lundi 31 mars 2008 à 07:47 -0700, J.T. Conklin a écrit :
> Does tao-naming also include nslist, nsadd and nsdel? For packaging,
> I'd think we'd want the associated utilities in with the package, or
> perhaps having a tao-naming-utils, etc. package as well if we're
> trying to minimize footprint.
Debian has a separate package, tao-utils, which contains nslist, nsadd,
nsdel, and tao-catior.
package tao-utils is recommended by package tao-naming, so it's
automatically pulled when installing tao-naming. (Well, it should be: I
have just found out it's currently broken: tao-naming recommends
tao-nsutils instead, and there's no such package.) But maybe tao-nsutils
(or tao-naming-utils as you suggested) is a better name?
> > In Debian we also have:
> > tao-ifr IFR_Service tao_ifr
> > tao-ft Fault_Detector Fault_Notifier FT_ReplicationManager
> > tao-ftrtevent ftrt_eventservice ftrtec_{factory,gateway}_service
> > tao-imr ImplRepo_Service ImR_Activator tao_imr
> > tao-lifecycle LifeCycle_Service
> > tao-load LoadManager LoadMonitor
> > tao-log {Basic,Event,Notify,RTEvent}_Logging_Service
> > tao-event* CosEvent_Service
> > tao-scheduling Scheduling_Service Dump_Schedule
> > tao-time Time_Service_Server Time_Service_Clerk
>
> I'm suprised that you've bothered to package some of these as
> installable packages, in particular the life cycle service, which
> is more of an example or unit test than a real, deployable, service.
Really? I was not aware of this. Any other service in the above list
that is not worth packaging?
> I'd tend to call the CosEvent service just plain event, or prefix
> every OMG "CosFoo" service with "Cos". It's only long term users
> that think of the RT TAO event service as "Event".
Are we talking about package or binary names here?
> On the other hand, it may be better to use names inspired by the
> official OMG spec, so TLS instead of log for the Telecom Log Service.
Agreed: tao-tls package name is better than tao-log.
What about the case and the word separator in the binary program? Should
the binary for load manager be named `tao_load_manager',
`tao_loadmanager' or `tao_LoadManager'?
I believe it should be easy to find the binary name from the package
name.
> >> We can rename the binaries when they are installed. Would it
> >> be better to name the Naming_Service something like:
> >>
> >> tao_naming
> >> tao_namingd
> >> taonamingd
> >> <something else?>
> >
> > I would prefer tao_naming (or tao-naming to match the package name).
>
> One of the first things we should look at is the catior utility, as it
> already conflicts with a similar utility from another ORB (I think
> OmniORB, but it might have bin MICO)
As I wrote above, in Debian it was renamed to tao-catior. But that's not
consistent with the `tao_' prefix, so this will have to be changed[1].
> With the autoconf build's --program-prefix, --program-suffix, and
> --program-transform-name options, we already have a great deal of
> flexibility in renaming the installed binaries. The GNUace build
> doesn't have this, but it doesn't really have an "install" mode
> either. We can look to add similar transforms when/if that work
> gets done/sponsored/etc.
>
> However, if binaries are going to be renamed, I'd prefer that they be
> renamed for all TAO installations, rather than just for
> packaging. Otherwise documentation and online support gets more
> difficult. This will be a bigger challenge, as the current names are
> hard-coded many places within the sources (unit tests, etc.).
Another option would be to provide two namespaces. The first one,
for /usr/bin, would contain binaries with the `tao_' prefix. The second
one, say /usr/lib/TAO, would be what's called $TAO_ROOT. The programs
here will match names in the documentation. In fact /usr/bin/tao_*
programs would be symlinks or wrappers to the real program in $TAO_ROOT.
This way software expecting a regular tree is guaranteed to work, and
binary renaming can be done later in $TAO_ROOT.
This does not solve the issue of binary names in /usr/bin, but eases the
transition from the current naming scheme to the next.
Regards,
Thomas
[1] other binaries renamed, to avoid conflict with existing programs:
mpc -> mpc-ace, mwc -> mwc-ace and gperf -> gperf-ace.
Ken Sedgwick
> The following TAO rpm packages deliver executable services:
>
> Package Name Executable Name
> ------------ ---------------
> tao-naming Naming_Service
> tao-cosevent CosEvent_Service
> tao-notify Notify_Service
> tao-trading Trading_Service
> tao-event Event_Service
> tao-concurrency Concurrency_Service
>
> Are these executable daemon names "distinguished" enough in a general
> namespace perspective?
Based on the helpful feedback to this thread I propose to rename the
following service executables when installed via RPM:
Package Name Prior Executable Name New Installed Name
------------ --------------------- -------------------
tao-naming Naming_Service tao_naming
tao-cosevent CosEvent_Service tao_cosevent
tao-notify Notify_Service tao_notify
tao-trading Trading_Service tao_trading
tao-event Event_Service tao_event
tao-concurrency Concurrency_Service tao_concurrency
I also propose the following utility names when installed via RPM:
tao_idl
tao_imr
tao_ifr
tao_catior [change]
tao_nsadd [change]
tao_nsdel [change]
tao_nslist [change]
The first three are already installed under these names. The last
four would be a change from prior installation naming.
Johnny Willemsen
> Based on the helpful feedback to this thread I propose to rename the
> following service executables when installed via RPM:
>
> Package Name Prior Executable Name New Installed Name
> ------------ --------------------- -------------------
> tao-naming Naming_Service tao_naming
> tao-cosevent CosEvent_Service tao_cosevent
> tao-notify Notify_Service tao_notify
> tao-trading Trading_Service tao_trading
> tao-event Event_Service tao_event
> tao-concurrency Concurrency_Service tao_concurrency
Why not have the executable have a _service postfix like now?
Johnny
Ken Sedgwick
Consistency with other services currently installed. And length.
J.T. Conklin
>> Based on the helpful feedback to this thread I propose to rename the
>> following service executables when installed via RPM:
>>
>> Package Name Prior Executable Name New Installed Name
>> ------------ --------------------- -------------------
>> tao-naming Naming_Service tao_naming
>> tao-cosevent CosEvent_Service tao_cosevent
>> tao-notify Notify_Service tao_notify
>> tao-trading Trading_Service tao_trading
>> tao-event Event_Service tao_event
>> tao-concurrency Concurrency_Service tao_concurrency
>
> Why not have the executable have a _service postfix like now?
Yes, it seems odd not to have some sort of suffix. They're not really
daemons in the conventional sense, so the traditional UNIX "d" suffix
doesn't seem to fit.
Without a suffix of some sort, the proposed name seem more like
commands that someone might run instead of services. This could be
mitigated somewhat by installing them in ${prefix}/sbin instead of
${prefix}/bin (Now that I think if it, this seems desirable to me
regardless of whether/how the executable names are changed -- please
share any thoughts you might have on this point).
I still think that having the Cos prefix for event and not for naming,
trading, notification, and concurrency services seems odd, especially
to one not used to TAO. And while we use Notify instead of Notification
as the binary name now, it really is the Notification Service.
Do you envision the "tao_" prefix being always used, or selected at
configure time with --program-prefix=tao_ ? The latter has the
advantage that if the user decided to install in a "DOC Group
Middleware" specific directory like /opt/doc without the prefixes. (I
have to say that aside from the conflict for catior, I've never had a
problem with the lack of prefixes and I tend to like the simple names,
but I don't feel strongly enough about it to object if that's the
consensus).
Related to packaging, I believe that all the standalone service
binaries default to loading a svc.conf from the current directory. If
we're moving in a direction where they're useful out of the box,
perhaps we should reconsider that so they don't pick up an arbitrary
file by accident. Or maybe load ${prefix}/etc/<service_name>.conf for
system wide defaults?
--jtc
--
J.T. Conklin
Ken Sedgwick
> Yes, it seems odd not to have some sort of suffix. They're not really
> daemons in the conventional sense, so the traditional UNIX "d" suffix
> doesn't seem to fit.
I think technically they are daemons since they run in the background
instead of under the direct control of a user (Wikipedia).
If we do want a suffix, then 'd' is the most common.
> Without a suffix of some sort, the proposed name seem more like
> commands that someone might run instead of services. This could be
> mitigated somewhat by installing them in ${prefix}/sbin instead of
> ${prefix}/bin (Now that I think if it, this seems desirable to me
> regardless of whether/how the executable names are changed -- please
> share any thoughts you might have on this point).
I think /usr/sbin would be a good location for these programs. I'll
make that change ...
> I still think that having the Cos prefix for event and not for naming,
> trading, notification, and concurrency services seems odd, especially
> to one not used to TAO. And while we use Notify instead of Notification
> as the binary name now, it really is the Notification Service.
Agreed, but if I remove the cos prefix from the event service it will
collide with the other event service (w/o the cos prefix). Is there a
better name for the other one instead?
Alternatively I'm happy to add a "cos" prefix to those without if it
makes more sense ...
Here are the names with:
1) cos added to all but the other event service.
2) 'd' appended
3) notify -> notification
tao_cosnamingd
tao_coseventd
tao_cosnotificationd
tao_costradingd
tao_eventd
tao_cosconcurrencyd
Are we there?
> Do you envision the "tao_" prefix being always used, or selected at
> configure time with --program-prefix=tao_ ? The latter has the
> advantage that if the user decided to install in a "DOC Group
> Middleware" specific directory like /opt/doc without the prefixes. (I
> have to say that aside from the conflict for catior, I've never had a
> problem with the lack of prefixes and I tend to like the simple names,
> but I don't feel strongly enough about it to object if that's the
> consensus).
I envision the tao_ prefix always being used (when installed by RPM
packaging).
Relocatable packages don't work well and are strongly discouraged by Fedora.
If we can choose a naming scheme which gives us consistency,
identifiability, namespace separation, and is not too clumsy to type I
think we are there.
Since "tao_" is so short, I think prefixing the installed executables
with it achieves all of the above goals.
> Related to packaging, I believe that all the standalone service
> binaries default to loading a svc.conf from the current directory. If
> we're moving in a direction where they're useful out of the box,
> perhaps we should reconsider that so they don't pick up an arbitrary
> file by accident. Or maybe load ${prefix}/etc/<service_name>.conf for
> system wide defaults?
The service init scripts installed by the RPM packaging use an explicit
conf file for each of the services. For example, the tao_cosevent init
script reads it's conf from /etc/tao/tao_cosevent.conf. It reads other
command line arguments from /etc/tao/tao_cosevent.opt.
Thanks for the feedback!
Thomas Girard
On Thu, Apr 03, 2008 at 12:36:40PM -0700, Ken Sedgwick wrote:
> J.T. Conklin wrote:
>
> > Yes, it seems odd not to have some sort of suffix. They're not really
> > daemons in the conventional sense, so the traditional UNIX "d" suffix
> > doesn't seem to fit.
>
> I think technically they are daemons since they run in the background
> instead of under the direct control of a user (Wikipedia).
>
> If we do want a suffix, then 'd' is the most common.
If we agree to add a `cos' prefix for OMG specified services, then maybe
this `d' suffix is not needed? (Assuming the `s' in `cos' stands for
service.)
> > Without a suffix of some sort, the proposed name seem more like
> > commands that someone might run instead of services. This could be
> > mitigated somewhat by installing them in ${prefix}/sbin instead of
> > ${prefix}/bin (Now that I think if it, this seems desirable to me
> > regardless of whether/how the executable names are changed -- please
> > share any thoughts you might have on this point).
>
> I think /usr/sbin would be a good location for these programs. I'll
> make that change ...
According to the FHS 2.3[1], sbin is for "system administration", for
root. I don't think running a TAO service is administrating the system.
Besides, since /usr/sbin is not usually in the user $PATH, it means the
TAO services will be hidden from the user.
> > I still think that having the Cos prefix for event and not for naming,
> > trading, notification, and concurrency services seems odd, especially
> > to one not used to TAO. And while we use Notify instead of Notification
> > as the binary name now, it really is the Notification Service.
>
> Agreed, but if I remove the cos prefix from the event service it will
> collide with the other event service (w/o the cos prefix). Is there a
> better name for the other one instead?
Slightly out of topic: what is exactly the difference between
CosEvent_Service and Event_Service?
> Alternatively I'm happy to add a "cos" prefix to those without if it
> makes more sense ...
>
> Here are the names with:
> 1) cos added to all but the other event service.
> 2) 'd' appended
> 3) notify -> notification
>
> tao_cosnamingd
> tao_coseventd
> tao_cosnotificationd
> tao_costradingd
> tao_eventd
> tao_cosconcurrencyd
>
> Are we there?
How about `tao_cos_' prefix? That would make another, easy to see,
namespace for OMG specified services.
> > Do you envision the "tao_" prefix being always used, or selected at
> > configure time with --program-prefix=tao_ ? The latter has the
> > advantage that if the user decided to install in a "DOC Group
> > Middleware" specific directory like /opt/doc without the prefixes. (I
> > have to say that aside from the conflict for catior, I've never had a
> > problem with the lack of prefixes and I tend to like the simple names,
> > but I don't feel strongly enough about it to object if that's the
> > consensus).
>
> I envision the tao_ prefix always being used (when installed by RPM
> packaging).
>
> Relocatable packages don't work well and are strongly discouraged by Fedora.
>
> If we can choose a naming scheme which gives us consistency,
> identifiability, namespace separation, and is not too clumsy to type I
> think we are there.
I'll follow the new naming scheme. Possibly I will provide backwards
compatible namespace in /usr/lib/TAO for a while.
> Since "tao_" is so short, I think prefixing the installed executables
> with it achieves all of the above goals.
>
> > Related to packaging, I believe that all the standalone service
> > binaries default to loading a svc.conf from the current directory. If
> > we're moving in a direction where they're useful out of the box,
> > perhaps we should reconsider that so they don't pick up an arbitrary
> > file by accident. Or maybe load ${prefix}/etc/<service_name>.conf for
> > system wide defaults?
>
> The service init scripts installed by the RPM packaging use an explicit
> conf file for each of the services. For example, the tao_cosevent init
> script reads it's conf from /etc/tao/tao_cosevent.conf. It reads other
> command line arguments from /etc/tao/tao_cosevent.opt.
Debian has no configuration files nor scripts yet.
Regards,
Thomas
[1] http://pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
Chris Cleeland
On Apr 3, 2008, at 4:01 PM, Thomas Girard wrote:
>>> I still think that having the Cos prefix for event and not for
>>> naming,
>>> trading, notification, and concurrency services seems odd,
>>> especially
>>> to one not used to TAO. And while we use Notify instead of
>>> Notification
>>> as the binary name now, it really is the Notification Service.
>>
>> Agreed, but if I remove the cos prefix from the event service it
>> will
>> collide with the other event service (w/o the cos prefix). Is
>> there a
>> better name for the other one instead?
>
> Slightly out of topic: what is exactly the difference between
> CosEvent_Service and Event_Service?
Isn't Event_Service the TAO-specific RT Event Service?
---
Chris Cleeland, Principal Software Engineer
http://www.theaceorb.com AND http://www.ociweb.com
Ken Sedgwick
> According to the FHS 2.3[1], sbin is for "system administration", for
> root. I don't think running a TAO service is administrating the system.
> Besides, since /usr/sbin is not usually in the user $PATH, it means the
> TAO services will be hidden from the user.
Agreed. For this reason I think the user programs tao_idl, tao_catior,
tao_nsadd etc should all be in /usr/bin.
But in the current linux service framework you need to be root to start
the other tao services we are discussing. Generally you use the
chkconfig command to specify that they should be started (or not)
automatically when the machine reboots.
They are similar to httpd (which is installed in /usr/sbin).
If we think the common use pattern is for users to run these from a
shell then we probably don't want to package them as linux services.
Thomas Girard
> > According to the FHS 2.3[1], sbin is for "system administration", for
> > root. I don't think running a TAO service is administrating the system.
> > Besides, since /usr/sbin is not usually in the user $PATH, it means the
> > TAO services will be hidden from the user.
>
> Agreed. For this reason I think the user programs tao_idl, tao_catior,
> tao_nsadd etc should all be in /usr/bin.
>
> But in the current linux service framework you need to be root to start
> the other tao services we are discussing. Generally you use the
> chkconfig command to specify that they should be started (or not)
> automatically when the machine reboots.
Okay, you need to be root to start TAO services using the service
framework. But these services don't have to be in /usr/sbin for the
service framework to work with them, do they?
> They are similar to httpd (which is installed in /usr/sbin).
Yes, but it's very likely that apache will listen on port 80, which
requires root privileges to work. I don't see the point putting binaries
in /usr/sbin if they don't require any special privilege.
> If we think the common use pattern is for users to run these from a
> shell then we probably don't want to package them as linux services.
My point was: why making it difficult for a user to run his own instance
of a TAO service? Leaving services in /usr/bin, you can have them work
with the service framework *and* any user can launch his own service.
For instance, a "system" naming service can be launched at boot time,
and a developer can easily test his ongoing work using his own naming
service.
Regards,
Thomas
Chris Cleeland
On Apr 3, 2008, at 4:07 PM, Ken Sedgwick wrote:
> But in the current linux service framework you need to be root to
> start
> the other tao services we are discussing. Generally you use the
> chkconfig command to specify that they should be started (or not)
> automatically when the machine reboots.
I don't think you want to run any of these things as root. They have
not been written with that level of security in mind.
wo...@dre.vanderbilt.edu
> On Apr 3, 2008, at 4:07 PM, Ken Sedgwick wrote:
>> But in the current linux service framework you need to be root to
>> start
>> the other tao services we are discussing. Generally you use the
>> chkconfig command to specify that they should be started (or not)
>> automatically when the machine reboots.
>
> I don't think you want to run any of these things as root. They have
> not been written with that level of security in mind.
Services started in this way almost never run as root, but as a special
unprivileged user. You would be crazy to run any network facing
application these days as root unless absolutely necessary ;-)
/-Will
Thomas Lockhart
> not been written with that level of security in mind.
The services script wrappers do typically run as root, but then execute
the daemon through su with a different user specified. So root is the
context where the executables are first located.
- Tom
--
Thomas Lockhart
Supervisor, Distributed and Real-time Group
Instrument Software and Science Data Systems
Caltech/JPL
J.T. Conklin
Ken Sedgwick <ksed...@bonsai.com> writes:
>> Yes, it seems odd not to have some sort of suffix. They're not really
>> daemons in the conventional sense, so the traditional UNIX "d" suffix
>> doesn't seem to fit.
> I think technically they are daemons since they run in the background
> instead of under the direct control of a user (Wikipedia).
When I think of daemon, I think of a program that does the daemonize()
dance to detach from the parent process, changes working directory to
/, closes all file descriptors, clones /dev/null as stdin, stdout, and
stderr, etc. The -ORBDaemonize command line option does some of that,
but in my experience it doesn't work well, I think daemonizing has to
happen earlier than ORB initialization.
All that being said, I won't argue against a "d" suffix --- I greatly
prefer it to nothing.
>> Without a suffix of some sort, the proposed name seem more like
>> commands that someone might run instead of services. This could be
>> mitigated somewhat by installing them in ${prefix}/sbin instead of
>> ${prefix}/bin (Now that I think if it, this seems desirable to me
>> regardless of whether/how the executable names are changed -- please
>> share any thoughts you might have on this point).
>
> I think /usr/sbin would be a good location for these programs. I'll
> make that change ...
Ok, I'll see what MPC/*.mpb/*.mpc changes will be necessary to specify
binary installation outside of ${prefix}/bin so Makefile.am generation
doesn't need any hand-tweaks.
>> I still think that having the Cos prefix for event and not for naming,
>> trading, notification, and concurrency services seems odd, especially
>> to one not used to TAO. And while we use Notify instead of Notification
>> as the binary name now, it really is the Notification Service.
>
> Agreed, but if I remove the cos prefix from the event service it will
> collide with the other event service (w/o the cos prefix). Is there a
> better name for the other one instead?
I don't know. Within the TAO documentation/community, there may be
understanding that the Event service is not really the Event service
described by Advanced CORBA Programming w/C++, etc.; but IMO this is
not clear to TAO novices. I know I made the same problem some years
ago... Anyone else have ideas?
>> Related to packaging, I believe that all the standalone service
>> binaries default to loading a svc.conf from the current directory. If
>> we're moving in a direction where they're useful out of the box,
>> perhaps we should reconsider that so they don't pick up an arbitrary
>> file by accident. Or maybe load ${prefix}/etc/<service_name>.conf for
>> system wide defaults?
The one case I was thinking of where this is especially important (but
yet completely forgot to mention) was the concurrency service. I
believe it's ORB must be configured in blocking mode in order to work
properly.
> The service init scripts installed by the RPM packaging use an explicit
> conf file for each of the services. For example, the tao_cosevent init
> script reads it's conf from /etc/tao/tao_cosevent.conf. It reads other
> command line arguments from /etc/tao/tao_cosevent.opt.
Can you explain a little how this works? Is this a rc.d script that
wraps the executable and provides the command line arguments?
--jtc
--
J.T. Conklin
J.T. Conklin
>> > Without a suffix of some sort, the proposed name seem more like
>> > commands that someone might run instead of services. This could be
>> > mitigated somewhat by installing them in ${prefix}/sbin instead of
>> > ${prefix}/bin (Now that I think if it, this seems desirable to me
>> > regardless of whether/how the executable names are changed -- please
>> > share any thoughts you might have on this point).
>>
>> I think /usr/sbin would be a good location for these programs. I'll
>> make that change ...
>
> root. I don't think running a TAO service is administrating the system.
> Besides, since /usr/sbin is not usually in the user $PATH, it means the
> TAO services will be hidden from the user.
Ken, Thomas,
I know you're both concerned with packaging for particular Linux
variants, but I think we need to be taking a larger view. Long before
the FHS or even Linux came into existance, /usr/sbin was understood to
be the location for system daemons and system utilities. I think TAO's
standalone service implementations fit that definition.
As for the services not being in the typical user $PATH, I think that
is a _good_ thing. I've been frustrated in the past when a daemon that
shouldn't or wouldn't normally be run by users is installed in /bin or
/usr/bin and ends up matching shell command completion (it was a minor
annoyance, which is probably why I can't remember the instance, but an
annoyance none the less).
Now the utilities, like nslist, etc., those should probably be
installed in ${prefix}/bin.
--jtc
--
J.T. Conklin
J.T. Conklin
Ken Sedgwick <ksed...@bonsai.com> writes:
> But in the current linux service framework you need to be root to start
> the other tao services we are discussing. Generally you use the
> chkconfig command to specify that they should be started (or not)
> automatically when the machine reboots.
Ok, I didn't get the implication of this when you talked about service
init scripts; but doesn't this really constrain deployment flexibilty?
For example, my system has two naming service instances, and I'm
experimenting with notification system federation by adding a second
instance of that as well. I'm not sure that any system deployment is
"standard" enough to be represented by a set of scripts provided with
the packaging.
--jtc
--
J.T. Conklin
Ken Sedgwick
>> I don't think you want to run any of these things as root. They have
>> not been written with that level of security in mind.
>
> The services script wrappers do typically run as root, but then execute
> the daemon through su with a different user specified. So root is the
> context where the executables are first located.
Yes, our scripts switch to user "tao" ...
Thomas Lockhart
> represented by a set of scripts provided with the packaging.
Certainly some users will want other configurations that a standard
script does not support out of the box (e.g. we typically have multiple
naming services running using the 1.0, 1.1, and 1.2 protocols).
But there is a standard configuration of one naming service using the
pre-defined port number which would be useful for most plain vanilla
configurations. Other services may be disabled by default (chkconfig
helps here) but the service scripts, enabled or not, are probably
essential for a complete distro package.
Ken Sedgwick
> Can you explain a little how this works? Is this a rc.d script that
> wraps the executable and provides the command line arguments?
Yes, we use the standard linux service recipe as much as possible.
I'll attach the scripts for tao_cosevent ... they are pretty
straightforward.
I think the installed location of the .conf and .opt scripts might
change; I suspect they should go in /etc/sysconfig instead of /etc/tao/
... still getting all the details hammered out ...
Thomas Girard
> > Slightly out of topic: what is exactly the difference between
> > CosEvent_Service and Event_Service?
>
> Isn't Event_Service the TAO-specific RT Event Service?
Then the binary name tao_rtevent (or tao_rt_event) might be more
appropriate?
Regards,
Thomas
Thomas Girard
> > Isn't Event_Service the TAO-specific RT Event Service?
>
> Then the binary name tao_rtevent (or tao_rt_event) might be more
> appropriate?
I meant tao_rteventd (or tao_rt_eventd) of course :-)
Thomas
Ken Sedgwick
tao_cosnaming
tao_cosevent
tao_cosnotification
tao_costrading
tao_rtevent
tao_cosconcurrency
Motivation:
I added an "rt" prefix to the non-cos event variant.
I envision these installed in /usr/sbin. Nothing prevents users from
running these binaries in different ways then the standard init
scripts, but they will have to add /usr/sbin to their path to do so.
I think this is appropriate.
I dropped the 'd' suffix because we have a "cos" prefix on most, which
implies service and they are located in /usr/sbin which implies they
are not user shell programs.
Unfortunately I'm on vacation next week and won't be reading email
after today until March 14th.