[Mageia-sysadm] planning for sysadmin task

[Romain d'Alverny]

On Tue, Oct 26, 2010 at 16:06, Olivier Thauvin
<nanardon at nanardon.zarb.org> wrote:
> * Romain d'Alverny (rdalverny at gmail.com) wrote:
>> On Tue, Oct 26, 2010 at 15:23, Michael Scherer <misc at zarb.org> wrote:
>> Sysadm. Per request of webteam.
>>
>> > - setup of infrastructure ( ie apache module)
>>
>> Sysadm. Per request of webteam.
>>
>> > - who is in charge of securing
>> >  - the servers
>> >  - each applications
>>
>> Both. Server security is going to be affected by application security
>> and this is the webteam role to control that part. And to assume/fix
>> potential issues.
> [...]
> Since you prefer to not using rpm, the work to setup such application
> get more complicated, especially if the sys admin don't know perl (in
> this case, the same apply to php apps, python, etc...).

I know this firsthand, from both sides, yes. That's the webteam
responsibility to provide this info for installing/upgrading the app,
and that partially requires from the webteam some knowledge about the
system.

So indeed, both teams need to know/understand each other.

> I don't like the "svn snapshot" way for officially in use web apps. It
> works for testing the devel version, but I'd really hope anyone
> working on web apps is able to have a clear roadmap and managing branch
> for quick security fixes.

Sure. But it happens to break nonetheless. What is crucial is not that
there is no breach (there will), it's that it is quickly reported and
fixed.

> And since you have a stable branch and a devel one, you are able to
> quickly redo a rpm.

I understand that but a RPM is an unnecessary step here IMHO. A web
app/development life cycle in dev/production is not the same as one
for a packaged app for a distribution.

All I care here as a Web dev/project manager is:
 - working on the app
 - making sure it works
 - pushing to prod
 - check again
 - iterate.

Pushing deployment from dev to production, assuming all tests pass,
should be ideally as fast as pushing a single button and waiting for a
few seconds. And it may not be a trivial thing either (not just
pushing files, but moving the app into several states for a clean
migration).

At some extent, RPM dependencies would be a useful thing for setting
up the application but this mostly happens once (first install) and
can be easily hosted within the web application itself (and then
handle the error) - WordPress and Drupal do it for instance.

I perfectly understand that this does not fit with the packaging
reasoning for a Linux distribution.


> Or are we assuming Mageia will not be able to provide security fixes as
> rpm for anyone using the distribution and so we prefer ourself to bypass
> them ?

Not related. If these are regular web apps, we may as well port
changes and fixes back to the upstream project (be it our own) and
have these repackaged. But packaging is not the focus of the webteam.


> BTW: who is the webteam ? Does CatDap (Buchan's apps) and MGA::Mirrors
> (mine) make us entering in webteam ? Is the Bs part of webteam works ?

The webteam, well, I'm preparing to shoot a first mail to people who
gathered on the wiki page; mostly developers and web integrators.
Nothing definitive, but I'm a volunteer to lead the first efforts for
the team.

About CatDap and MGA:Mirrors, yes, hopefully. That makes you part of
it in that other webteam members should be aware of this app and
reciprocally, all members should collaborate.

The BS is a separate kind of a beast but indeed, parts of it could
definitely benefit from web team developers/integrators (code,
organisation, design/graphics/UX levels).

So we can discuss this further with other future webteam members but I
will seriously not manage a production environment that goes through
packaging for app updates.

That does not mean I don't care about security - that means that
there's a balance to find and that web developers have to be in charge
of their apps security as well. So if that means we need to have
separate servers to isolate risks, so be it. If that means we need to
go for a different type of hosting, so be it.

And I don't say that harshly. :-p just in case.


Romain