[Solved] Arhitecture for custom repo [/Solved]

starMo · 2015-04-30 07:19:20

Hello,
Writing to you because I need help. I'm making a private repository, and I need some architecture like this diagram.

Let me try to explain you my needs, NOTICE: I'm not looking for a done product, only ideas that I'll accomplish.
Ok I have a BASE main repo, this db will hold things that are releated to my main updates, such as kernel or similar system updates/edits. Imagine the A,B,C as my clients, and A1 as a system under Client A and so.
Now I'm looking for a solution that will help achive this:

I want all the clients to use main repo (BASE), and also to use their own repos A,B,C. also I want the A1,B1,... to use BASE and their clients main repo A,B,..
Now the thing is that this needs to be achived under one server with ability to create new client (D) and somehow allow users to install D through BASE without allowing other clients (A,B,C) to install the repo.
Also subclients A1,B1,.. are also using BASE repo.

Basicly BASE repo is the main repo for system updates, A repo handles all under things releated to clients needs, and so.

I tought if somehow pacman has password protected packages but couldnt find anything like that, and I'm also looking for some advice that will help me keep seperate these repos, I tought of using gpg.
I think the main problem is ability of creating a new client and allowing new users to install the repo (D) with some type of authentication.

Last edited by starMo (2015-05-04 07:00:29)

runical · 2015-04-30 08:26:10

I'm not sure I understand. Let me try to sketch the situation:

You have a server with packages/repositories
You have three client computers/systems, each with their own repo requirements
Clients are not allowed to access the repository that is not meant for them
It must be easy to add a new client with their own repository.

Did I get that right?

First off, it would be nice to know why you need this setup. It might help us with determining if there might be a better solution.

The easiest solution I can think off is to just put the packages on a http server, divide the in the relevant repositories and then set up the local computer to just point to the relevant repositories. Like how the official repositories are set up.
Another option is to sync the relevant packages to the local filesystem using something like rsync and add a local repository. The disadvantage of this method is that it might take up a lot of space locally.

starMo · 2015-04-30 08:33:12

You got it allmost runical, only you forgot.

All clients can access the BASE repo

New Clients should be able to install their repo through BASE repo

First off, it would be nice to know why you need this setup. It might help us with determining if there might be a better solution.

Sorry I'm just unable to give you more information about it, business secrets.

The easiest solution I can think off is to just put the packages on a http server, divide the in the relevant repositories and then set up the local computer to just point to the relevant repositories. Like how the official repositories are set up.

I'm not sure how can I solve the installation of new clients.

Thank you for your reply.

runical · 2015-04-30 09:11:51

starMo wrote:

First off, it would be nice to know why you need this setup. It might help us with determining if there might be a better solution.
Sorry I'm just unable to give you more information about it, business secrets.

Ah, OK. It happens

The "installing through BASE" requirement seems troublesome in its current form. The only way that would work is by giving every client different gpg keys and hoping that that they aren't smart enough to use --skipgpgchecks if they really want to install the packages they aren't supposed to. It is not foolproof and it will probably be broken soon.

There is an idea I'd like to propose: You can look into getting a per client package which sets up the correct mirrors etc. This package can be distributed by their own repository for updates and installed the first time around using pacman -U. Or, distribute a program that takes a login and then sets up the required repositories.

Creating an installation medium for every client with the required setting on it seems like a good idea as well.

Mind you, I'm just spewing ideas. If you need me to clarify what I said here, please ask.

EDIT:

The easiest solution I can think off is to just put the packages on a http server, divide the in the relevant repositories and then set up the local computer to just point to the relevant repositories. Like how the official repositories are set up.
I'm not sure how can I solve the installation of new clients.

Just give them the address I just remembered, if you set it up as a http server, everyone will be able to get to every repo if they want to. Maybe rsync will be better.

Last edited by runical (2015-04-30 09:15:00)

Lone_Wolf · 2015-04-30 13:50:41

StarMo,

I think it may be easier to setup the security on the clients, not on the server.

Are you using ACLs ?

If so, ACLs + /etc/sudoers could be used to restrict access to important files and commands.

For special cases sudoers would have aliases (like allowing some users to update) .

If your setup includes LDAP authorization, it will make it easier to make this setup manageable.

progandy · 2015-04-30 14:12:54

I have an interesting idea: Use the HTTP basic auth scheme to identify the system.

pacman.conf (put this in your default installation)

[system-base]
Server = http://example.com/public/$arch

Include = /etc/pacman.d/system-specific.conf

system-specific.conf (permissions: 0600, uid root, gid root)
This file might be distributed as a package in base, for example package-system-a:

[system-a]
Server = http://user:pass@example.com/server-a/$arch

or package-system-b-2:

[system-b]
Server = http://user:pass@example.com/server-b/$arch

[system-b-2]
Server = http://user:pass@example.com/server-b-2/$arch

Now, root users of your systems can break that and share the repository password with others, but root users are always able to simply share packages from the pacman cache.

Edit: You can extend this idea and force each root user to register a verified account for the repositories. Then you will know who downloads from a repository. If the downloads from a specific user id are too frequent (and from different ips) you know who has shared the access information. In this case, provide an application that asks for the username and password and then writes the system-specific.conf.
Edit: I suggest you don't let the users choose the password, but provide it in form of an API-key like it is common for webservices. You could also require the user to request a new session key that is only valid for a limited time (3 hours) each time.

Last edited by progandy (2015-04-30 14:28:56)

starMo · 2015-05-04 06:38:58

@Lone_Wolf and @progandy.

First of, I'd like to thank both of you for your replies, I appreciate them both.
And I've managed to setup it, using HTTP Authentication method with few security tricks
Its allmost like you explained progandy, I'd like to encourage you guys to try makeing your own, it's pretty cool

This topic can be closed, if no one has any missunderstanding

runical · 2015-05-04 06:43:01

Just mark the topic as [solved] by editing the first post (prepend it to the title).

starMo · 2015-05-04 07:00:38

Done

Arch Linux

#1 2015-04-30 07:19:20

[Solved] Arhitecture for custom repo [/Solved]

#2 2015-04-30 08:26:10

Re: [Solved] Arhitecture for custom repo [/Solved]

#3 2015-04-30 08:33:12

Re: [Solved] Arhitecture for custom repo [/Solved]

#4 2015-04-30 09:11:51

Re: [Solved] Arhitecture for custom repo [/Solved]

#5 2015-04-30 13:50:41

Re: [Solved] Arhitecture for custom repo [/Solved]

#6 2015-04-30 14:12:54

Re: [Solved] Arhitecture for custom repo [/Solved]

#7 2015-05-04 06:38:58

Re: [Solved] Arhitecture for custom repo [/Solved]

#8 2015-05-04 06:43:01

Re: [Solved] Arhitecture for custom repo [/Solved]

#9 2015-05-04 07:00:38

Re: [Solved] Arhitecture for custom repo [/Solved]

Board footer