Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 May 2003 19:01:17 +0300
From:      "Maksym Shevchenko" <r0land@r0land.kiev.ua>
To:        <omestre@freeshell.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: production...
Message-ID:  <034601c31ee9$0d4cdc20$8300a8c0@pepelac>
References:  <20030520131537.3395210214@ws-tor-0004.procergs> <1053437797.1444.5.camel@hx.nist>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Artem!
You wrote to <freebsd-hackers@freebsd.org> on 20 May 2003 17:36:39 +0400:

 AZI> In Tue, 20.05.2003, at 17:15, omestre@freeshell.org wrote:
>>  I'm talking about, "maybe", scripts to "jail" the operator in his
>> job. I'm talking about administration tasks that we  are making every
>> day, but without a environment to this. A  framework to be changed,
>> shared, and no more command prompt.
>>  "Imagine" a server managed by menus, in diferent levels, but well
>> structured. With functions, chances to edit file...
>>  Sorry by the english, and i hope that you can understand what i mean.
>>  Any answers will be cool.
 AZI> Instead of image of such server i remembered a linuxconf... Nah,
 AZI> that's not the thing I want on my server.
 AZI> I really love shell, since absence of all this windows `Click-n-go'
 AZI> fuss makes me really think, what and how should be done to get a
 AZI> really Good
 AZI> Things(TM) as result.

It is possible that he means other thing useful. As example, in hosting
solutions with a numbers of hosting on each server, keeping configuration of
each service (as usual - dns, mail, http (dynamic & static content), ftp,
telnet/ssh, some kind of sql) in decentralized files are not too simply. I
never seen systems (but had try to build) that will keep configuration for
such hosting centralized database (possible with simply export to usual
configuration files).
For instance in such tree:
----------------------[begin of instance]---------------------------
1) Agreement information
    a. Contact information
    b. Agreement number
    c. Expire date
    d. ...
2) DNS
    a. Allowed
    b. Primary "superns1.superhosting.com"
    c. Secondary "superns2.superhosting.com"
    d. Name zone 1 (SOA entry)
        i.  Entry
        ii. ...
    e. Name zone 2
        i. Entry (MX)
        ii. Entry (IN A)
        iii. ...
3) Mail
    a. SMTP
        i. Disallowed
        ii. ...
    b. POP3
        i. Allowed
        ii. ...
4) Web Hosting
    a.  Allowed server "apache043.superhosting.com"
        i. Root dir "$HOME_APACHE043/user/htdocs"
        ii.  CGI dir "$HOME_APACHE043/user/cgi-bin"
        iii. ...
5) Ftp
    a. Allowed server "apache043.superhosting.com"
    b. ...
6) Telnet/SSH
    a. Disallowed
7) SQL
    a. PostgreSQL
        i.  Disallowed
    b. MySQL
        i. Allowed server apache043.superhosting.com"
            1. Data dir "/home/user/sql/data"
            2. Used local socket "/home/user/sql/sock.tmp"
            3. Network socket "disallowed"
            4. Bin dir
            5. ...
----------------------[end of instance]----------------------

What about such centralized configuration systems?

--
With best regards, Maksym Shevchenko.
E-mail: r0land@r0land.kiev.ua



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?034601c31ee9$0d4cdc20$8300a8c0>