[oi-dev] Barman packaging

Nikola M. minikola at gmail.com
Thu Nov 7 08:03:41 UTC 2013


On 11/ 7/13 08:39 AM, Alexander Pyhalov wrote:
>
> The most interesting part is that barman has to run rsync with 
> postgres euid on remote site (to access DB files ) and with barman 
> euid on local (to access backup files). I think that converting 
> postgres from role to user is more straightforward than trying to 
> create necessary RBAC policy.

I think that local implementations and needs should not dictate what 
will be changed in OS distribution itself.
If people don't know how to use RBAC they should learn it (me included)
if programs needed to run on OI don't support platform, they shoud be 
patched to work right.

I don't understand why I should loose PostgreSQL role on all systems I 
would probably install in the future, because someone personally had a 
problem with one program not made for the platform.
And what it has to do with that particular implementation of external 
program
and what rsync have to do with Solaris roles.

It could be written on wiki how to do that, it could be written on 
package description, it could be written on the program manual how to 
make it work
but the OS should not be slave of the application and kill existing 
functionality that people rely upon, just to be able to run one 
additional program without patching it for the platform.

Large installations usually have their own mirrors and changes that for 
some reason some local admin thinks theya re needed for them, and not 
for the rest of the world,
can land on their internal mirror.

Besides, we have 'zfs send' and using rsync for that is sort of stupid 
to me.
Why that app should not be patched to use zfs snapshots?

You could think this way: everything could be on roles in the future, 
like it is in Solaris11.
They killed root account completely. And we still have root account, and 
that is maybe good thing,
but that does not mean we should start killing roles because we find it 
interesting at the moment to run some additional app.
Let's think our way and not turn everything in Linux.

So I think it is not such good idea to kill one large-known 
functionality, just to satisfy random App without patching it.
Are we actually suffering for not having established review and 
discussion process before implementing changes?





More information about the oi-dev mailing list