[Bug 613023] New: Setup new master.gnome.org



https://bugzilla.gnome.org/show_bug.cgi?id=613023
  sysadmin | Other | unspecified

           Summary: Setup new master.gnome.org
    Classification: Infrastructure
           Product: sysadmin
           Version: unspecified
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: Other
        AssignedTo: sysadmin-maint gnome bugs
        ReportedBy: bugzilla-gnome vitters nl
         QAContact: sysadmin-maint gnome bugs
      GNOME target: ---
     GNOME version: ---


Currently many people have access to a shell account on master.gnome.org just
to run install-module.

Though people should be trusted before allowing shell access, the more people
who have shell, the more 

likely things can go wrong. Further, as everyone has access to the 'real' ftp
location, things can get 

messy (see sources/gazpacho: it has binaries in there). Further, some modules
use strange version 

numbers. :-(

I propose setting up a master.gnome.org which:
1. Has a ChrootDirectory
2. Only allows sftp using "internal-sftp" ForceCommand
   ==> No more shell access!
   ==> Can this be done in a authorized_keys file? Or do we need a sshd_config
Match command? IIRC not 

possible in RHEL5
3. Access is solely determined from .doap files
4. Lives as a VM on combobox

>>> ChrootDirectory <<<
On master.gnome.org there should be a directory structure which looks like
(chrooted):
/
/sources
/binaries/linux
/binaries/mac
/binaries/win32
/binaries/win64
/errors

People do NOT get access to the real /ftp/pub/GNOME unless they have specific
needs.

Either via cron or via inotify a new version of the install-module script is
called. This script 

validates every new file and places it in the correct location in
/ftp/pub/GNOME. The script should be 

somewhat smart: Placing a file in sources directory means it will go into the
sources directory. 

However: sources files MUST end with .tar.gz or .tar.bz2. However, perhaps some
files are allowed to be 

stored in just /. Not sure yet.

Files placed in the root will be determined automatically.

In case there was an error validating the file it is moved to /errors. On
success the file is removed 

from the chroot.

Informing of user:
User receives an email *always*. Subject field should be clear.

This script should live in sysadmin-bin Git module (currently it resides in
releng). I have a partial 

script in /usr/local/bin/py-install-module on window. The new Python version
will NOT work exactly like 

the existing version.


>>> ftpadmin group and shell access <<<
Everyone is removed from this group. People who really have specific needs will
have to request access 

again. This will result in people *NOT* having shell anymore. I expect a big
backlash with this, 

especially as some people are hosting various things in their ~/public_html.

>>> DOAP files and access <<<
Currently anyone can upload anything they want. In future:
1. Any release will be emailed'ed to *all* the maintainers (as determined from
the .doap files)
2. Any access change will be emailed to all the current/previous maintainers
3. When gaining master.gnome.org access, user should get an email with
instructions for master.gnome.org

>>> Modules not in git.gnome.org <<<
Not sure what to do. There have to be exceptions for either people (release
team) or modules 

(gstreamer). Perhaps hard-code modules? (gstreamer, intltool). New group
perhaps?

>>> VM on combobox <<<
Need a public IP address

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the QA contact of the bug.
You are watching the assignee of the bug.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]