Centralised Repository Manager

[stuartiannaylor]

There has been interest in apt-cache / apt-mirror centralised repository control. This would provide control over client updates and reduce wan traffic of client updates.

I think this would add much to the community running OS desktop clients.

Both apt-cacher and apt-mirror in a simple analogy rsync the ubuntu repo to a local directory and use apache (http:) as a repository provider.
This allows much in terms of security and also allows the addition of localised (server environ) packages.

Rather than just a cache and update frequency control could it not be expanded to a manager.
In that the provider method could be filtered to a user/group object/group level and provide a convenient method of software control. This negates the need for additional modules such as the saltstack or puppet would require. It would use the rollback and methods that apt is hugely successful at natively?

Stuart

[kernevil]

Hi stuart,

I think that a module such saltstack is still needed. If I understand correctly, your idea is to configure the clients to install all packages from the cached/mirrored repository, but this way you won't be able to remove software from the server administration panel.

Cheers

[stuartiannaylor]

I am thinking that to remove software you need the full dependency list ....
So if you where to remove it from the Repo then you would leave apt wondering what do I do with this?

My main argument for a dynamic centralised repo was that it would be local and it could be dynamic depending on the network object or user object.

I have just been trying to think of methods that would represent the lowest common denominator without adding further modules or methods. Trying to keep it as native as possible which hopefully will keep the system open without becoming to specific for a singular environment.

Removing items from a Repo after a client has pulled items from that repo would be a bad idea. In fact I don't really think its necessary but I have just been throwing some idea's out for comment.

It would be possible to provide a mechanism to apt-get install this-network-object or apt-get install this-user-object.
The client / server authentication methods are already there so would it be possible to create the above two installer packages to allows have the same apt object name but provide different results based on a centralised network-object / user-object control format?
The this-network-object would be a script of apt-get install lines for that machines software
The this-user-object would be /etc, polkit templates for that user.

dpkg –get-selections gives what is installed in a client and I am just wondering if we need to go to the level of saltstack but maybe as I haven't a clear roadmap.

Maybe it is puppet but I do have a feeling that in the 80-20 rule we already have the mechanisms we just need to provide common control methods.

Stuart

[ichat]

to implement this would require the use of meta packages  whitch in my opionion is basically good practice  BUT once you use metapackage for stuf like     zentyal-firefox-settings.deb  and  openoffice.org-zentyal-dlapsettings.deb -   you dont even need to change the  apt casher,  because instead you could impement a filter to the 'ubuntu software center'    that simply doesn't list  unnead / undesired apps...

so basicly this would turn arround and  become,  " what method will i push this  list of apps with...   
what kind of software am i going to use that auto-checks  and isntalles updates,  but also removes them again when apps are revoked....?   "  once again...

changing the list / appearence of a repository  to me sounds more like finetuning the cosmettics  rather than inplementing the feature...

[stuartiannaylor]

Honestly haven't a clue what you mean?

[robb]

I think what ichat means is just to use 1 repository for your system and applications and make that a local repository. This can be done to just have 1 repository in your sources.list (and make sources.list only readable for U:G:W)

2nd Step would be creating a filter in your local repository that only lists those packages that are allowed by the network administrator. Then standard apt-get mechanisms will do it's work for installing AND de-installing packages.

Personally I would prefer to see this happen from a webinterface on Zentyal Server, similar to the packagemanager in the 'Software Management' section, for instance in a new 'Desktop' tab. To have more flexibility in assigning software packages to different types of users, create a groupbased authorisation mechanism. If someone is member of Thunderbirdgroup, he gets TBird installed etc...

[stuartiannaylor]

changing the list / appearence of a repository  to me sounds more like finetuning the cosmettics  rather than inplementing the feature...

I didn't have a clue to the above sentence but was generally having one of those moments.

As part of the community I have been throwing up some idea's that are based on a few problems I have with general admin.
Generally the response has been negative and this has caused annoyance. I have an opinion and a vain hope that the community will lead and discuss development. My annoyance was that practically all replies where that the methodology proposed was wrong. The functionality of desktop control centralised in Zentyal would be a great addition for the admin. It would of been great if alternavite methodologies to provide similar functionality had been provided.

Anyway ....

The only time you would want separate repositories is if you are running multiple clients say Debian, CentOS...
This is part of a push to keep Zentyal open. Also with the current roadmap there is a strong possibility that we might see fat client Ubuntu LTS and thin client Lubuntu.
It just occured to me the repository synchronisation and delivery methods are very similar across the board and it would be blinkered to just concentrate on a singular desktop distribution.

The mirroring could be easily accomplished with rsync. The delivery is http so via Apache in the current case. So I fully agree that depending on user/group or network object/group dynamic filtering based on permissions could control available apps.

The idea is that Puppet for an SMB situation is slightly heavy and to provide alternatives. Polkit can be used for software control but first you have to get the polkit to the user. I am a fan of in very basic terms:-

Some form of centralised sofware control that can push or be pulled at 2 levels. Firstly the client via network objects. Secondly the user via user objects.

Its completely non microsoft and an alternative to forcing Linux to M$ AD and group policies as the 2 don't really match. Also why should we ?

I would be much more interested in some rough idea's of how the server interface would operate and how much interest there is for non microsoft clients?

Stuart

[ichat]

sorry for the late response,   but that was exactly NOT what i mean,

when you just run a local repo, its nice because  on  new installations it saves you a lot of bandwidth (which is good when you (have to) share a consumer grade dsl or cable connection with 20 or so employees)

but in my opinion is not a verry good way of solving this issue.  and since we allready have quality assured software updates, i would even say that 'that option'  almost completely dismisses  this feature request altogether if its not about bandwidth-controll. 

a scripting engine, the means to distinguish groups of people's and groups of computers
(user domains and computer domains),  a way to push commands to run on all selected machines or in user profiles,  and finaly a nice webinterface to manage install sellect and create these kind of scripts in my view would be a big deal more intresting.  because it would not just be about  wsus (selecting if an update is accepted or rejected),  but also about configuring the desktop, preventing users from changing thair workstations, and any other things that could have been done with group-policies..   

[stuartiannaylor]

Ichat this is exactly what I have been talking about. Instead of being negative about a proposal could you expand on how you would enable M$ group policies through AD to provide control mechanisms for Linux clients?

Stuart

[robb]

Maybe I have another grasp of how to implement the 'WSUS-like' local repository, but in my view it is a bit more than just allowing or disallowing upgrades of packages. I would like to see it as a means of assigning a group based selection of applications.
In my view it's a matter of creating groups for each application (or if several applications are considered 'standard' put them in a 'base installation' group) If someone is member of a certain group, the application will be installed on the system he works on and the application is available through the applicationmenu (in gnome, kde etc) or Dash (Unity)

The question is, if an application should be de-installed when the useraccount is removed from the corresponding applicationgroup. Or will it be sufficient to just 'hide' the application from the menu so it can't be launched anymore? (should be possible with a profile manager like Sabayon or equivalent)

This way we will benefit from both apt update manager so we can not only install and update packages, but also de-install packages, and Sabayon-like profile manager to manage privileges.

[stuartiannaylor]

I have moved the thread to http://forum.zentyal.org/index.php/topic,9539.msg39682.html#msg39682 as it has a poll and it is more about asking the community what they think will suffice for the SMB Niche Zentyal represents.

I think the centralised repository is an excellent idea "''WSUS-like' local repository" is a fairly simple affair. Zentyal provides automatic updates and you can select either automatic or manual.
A central repository with similar control would allow a sysadmin to control the central repo. You can either set the central repository to auto update or update manually. Or even on a cron schedule if you so wished.

I am going to continue on 'WSUS-like' local repository and if anybody else would like to chip in with any alternatives then please do so.

Stuart