Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ShelLuser]

This is a very blunt re-done "copy" from the temporary SearchIRC forum but I think it has its use so here we go again (and please guys, try not to lose all these posts this time ).

Solaris is an Unix operating system developed by Sun Microsystems and has recently been made available for free. No matter if you wish to use it privatly or on a commercial basis. As a small sidenote; even additional software, like a complete network suite ((web)mail, web, application, portal, calendar, identity -server completely free) or a 'remote desktop' are now freely available.

Due to its enhanced security I think its an ideal platform to use for IRC services. And with the latest release you have many options to fully secure and lock down your services from your other processes. You can even reduce the otherwise increased risks of running unstable to virtually the same levels as the stable Anope release. But thats going ahead of things.

First thing to do is to check what you have and want. Solaris ships with all the components you may need for Anope (gcc compiler, MySQL, libraries, etc) but because some things are located on other locations an installer like Anope's might have some problems finding, for example, the MySQL include files or libraries. When this happens there is no need to panic.. Just check the "config.log" file which is being created to see what command line parameters 'Config' used to start the 'configure' script. Then check the configure helpscreen (./configure --help | less) to see what parameters you'd need to specify MySQL and you'll be all set.

Installing and configuring Anope really isn't much different from other environments but it starts to become interesting when looking at a way to automaticly (re)start Anope. On Linux you may have setup an rc.d file in /etc/init.d and a cronjob to check the status of the services. On Solaris there no longer is any need for that, if you're going to utilize the new Service Management Facility (SMF). This service has been setup to replace the old rc.d scriptfile structure in order to offer a more robust and versatile way to manage and protect your services. This is done through so called manifests which are basicly XML files which describe a certain service in detail.

A big advantage over the regular rc.d scripts is that SMF will make sure that your service remain available. So in the event of a crash it will be detected by SMF after which it will re-start the service. Ofcourse this can also give you some disadvantages; for example when an oper needs to shutdown the services remotly and wishes to do so through OperServ. If you set things up in a default way then the services will go down, only to be restarted again. It can be overcome, but thats beyond the scope of this post.

Another very big advantage are the so called privileges. You can somewhat compare this system with SELinux. In short; this system can be used to leave the old Unix model where you have one admin user (root) which has all full control and regular useraccounts. Instead you can grant a regular account control over a certain service. But the interesting part is that you can also deny access to certain features. Whats more; this can be done with inheritage. For example; I can create an IRC useraccount which can execute programs, but also tell the system then when it executes something that all other spawned processes won't have this privileges. On my servers I usually deny the IRC user to study other processes running on the system. For example:

Code: [Select]

$ id
uid=503(irc) gid=103(irc)
$ ps -ef | wc -l
       4
$ ppriv $$
20049:  -sh
flags = <none>
        E: basic,!proc_info,!proc_session
        I: basic,!proc_info,!proc_session
        P: basic,!proc_info,!proc_session
        L: basic,proc_chroot,proc_setid
$ magi:/home/peter $ id
uid=100(peter) gid=10(staff)
magi:/home/peter $ ps -ef | wc -l
     133
While it isn't a good idea to blindly rely on all these features to present you with a secure environment it can make your life a lot easier when it comes to maintaining such services.

To close down let me present you with a specific example of a manifest file which I use to control my Anope services. I'll do so in the next post since I'm not sure how long a message may get on this forum...

[ShelLuser]

In order to setup a new service you'd need a manifest. The usual location for these files is /var/svc/manifest and in this case I'd put this file in the "application" subdirectory, perhaps even creating a seperate "irc" directory so it can hold all your services together (so for example you could use /var/svc/manifest/application/irc).

Here is the manifest file (services.xml) which I use:

Code: [Select]


<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='IRCServices'>
<service name='application/irc/services' type='service' version='1'>

   <single_instance />

        <dependency
                name='filesystem'
                grouping='require_all'
                restart_on='error'
                type='service'>
                  <service_fmri value='svc:/system/filesystem/local' />
        </dependency>

   <dependency
      name='network'
      grouping='require_all'
      restart_on='error'
      type='service'>
        <service_fmri value='svc:/milestone/network' />
   </dependency>

        <dependency
                name='irc_server'
                grouping='optional_all'
                restart_on='none'
                type='service'>
                  <service_fmri value='svc:/application/irc/ircd' />
        </dependency>

   <dependency
      name='configuration'
      grouping='require_all'
      restart_on='none'
      type='path'>
         <service_fmri value='file://localhost/usr/local/irc/anope.conf' />
   </dependency>


   <exec_method
      type='method'
      name='start'
      exec='/usr/local/irc/services'
      timeout_seconds='30' >
        <method_context>
          <method_credential
            user='irc'
            group='irc'
            privileges='basic,!file_link_any,!proc_info,!proc_session'
            limit_privileges='basic,proc_chroot,proc_setid' />
        </method_context>
   </exec_method>

   <exec_method
      type='method'
      name='stop'
      exec=':kill'
      timeout_seconds='5' />


   <instance name='default' enabled='false' />

   <stability value='Evolving' />

</service>
</service_bundle>

As you can see I have my services located in /usr/local/irc. Here the main binaries and config files reside, the rest of the datafiles are located in an "anope" subdirectory. This script sets up a few things:

Dependencies - The service depends on the filesystems being available (/usr/local is a seperate filesystem on my box) and if some error occurs with the filesystems during run it will (try to) restart the service. Next it depends on the network where the same situation applies. The next dependency block sets up an irc_server dependency. Just like the services I also wrote manifests for the rest of the IRC stuff. So this makes sure that the services will always have an irc server available to connect to.

Note that I have changed the priority from 'required' to 'optional'. This is done so that this manifest will also work if you don't have an "irc_server" defined. (you can ofcourse also leave out this entire dependency block).

Last but not least is the config dependency. Without the 'anope.conf' file the service won't start. You may need to change this since the normal Anope configfile would be located in /usr/local/irc/anope/services.conf. But because I like to group my IRC config files a little I created a symlink which points to the anope.conf file. Your milage may vary.

Execution - The last blocks are used to define the way the program starts and stops. As you can see it uses the "irc" userid and groupid, without those this manifest won't work. Next it sets up the permission bits which I described in my previous post. While this won't majorly secure your box it will present you with a limited environment when it comes down to a possible compromise. The reason I used this approach is because my IRC services are running on a seperate virtual server.

How to use this..  If you copy the code block above and dump this in a file /var/svc/application/services.xml then you can use the "svccfg" command to import this manifest. You can do this using "svccfg import services.xml". After that you can check if everything went well by using "svcs". For example:

pandora:~ $ svcs -l irc/services
fmri         svc:/application/irc/services:default
enabled      true
state        online
next_state   none
state_time   Wed Nov 16 23:24:01 2005
logfile      /var/svc/log/application-irc-services:default.log
restarter    svc:/system/svc/restarter:default
contract_id  8656
dependency   require_all/error svc:/system/filesystem/local (online)
dependency   require_all/error svc:/milestone/network (online)
dependency   require_all/error svc:/application/irc/ircd (online)
dependency   require_all/none file://localhost/usr/local/irc/anope.conf (online)
pandora:~ $

Here you can see that my service is running, it was started in November last year (yeah, I really need to put 1.7.13 on :-)) and it also has all the dependencies in place.

Like I said above you may need a little tweaking in order to make this fully work since this file is fully aimed at my environment. But despite that I hope it may be usefull to someone.  And if you need further help don't hesitate to post.

Have fun!

[FiXato]

This is a very interesting post and quite worth testing it some day
*needs to get his old test-box up and running again..*

Thanks for the description !

One question though, what is 'milage'?

[ShelLuser]

Originally posted by FiXato
One question though, what is 'milage'?

Milage is normally a verb indicating a lenght or distance in miles. But in this case its used as a saying. "YMMV" - Your Milage May Vary. In other words; while these scripts work excellent for me it doesn't mean they'll immediatly work fine on other people's setups as well.

EDIT -> hehe, well, only after I typed all this up and re-confirmed my story with dict.org I see what you meant.  No, in this case "milage" is simply a wrong way to type "mileage" :-)

[Edited on 1-3-2006 by ShelLuser]