Poll - Vote if you like this Central, Internal, Software Repository Implementation

[dvarsam]

Hello!

I have bumped into many posts where users ask for a Central, Internal Software Repository.
The idea is this:

1. You have a Network with 20 PCs. All of them are equipped with the Ubuntu OS.

2. The Ubuntu Update of Packages should be downloaded on one PC & the rest of the PCs on the Network should upgrade from the Repos of that single PC.

So, instead of downloading the Ubuntu Updates 20 times (or one time, and then copy & paste all those download Packages 20 times), I suggest the following:

1. Currently, If you launch Synaptic Package Manager (from Menu, select "System\Administration \Synaptic Package Manager"), then from the Menu select "Settings\Preferences" & click on the Tab named "Files", you get the following window:



2. The new version should be this one:



Note:
In the above version, instead of all the Ubuntu upgrade packages be downloaded on the default folder "/var/cache/apt/archives", you can choose/create any folder you wish instead!

3. In the same way, the remaining 19 Networked PCs will have the following settings:



Note:
1. That means their Ubuntu upgrade package folder is targeting/linking to "192.168.1.2.:/var/cache/apt/archives" or any other folder you want!!!
And the target address "192.168.1.2" is of that 1rst PC that downloaded the Ubuntu upgrade packages!
Now, if the target folder is empty or contains some packages instead, then the Networked PCs download these files themselves, but save those new packages inside the above designated folder - i.e. the "192.168.1.2.:/var/cache/apt/archives".


Please vote if you like the current suggestion:

1. Yes, this is how I want this to work.
2. No, I don't like this - I prefer how things currently work.
3. I would like this to be implemented differently - please explain how...

Thanks.

[Tomosaur]

This is pretty much unnecessary if the server version is used in a thin-client network. Only the server ever needs to get updated, the other computers just use the server's software.

[maniacmusician]

sounds pretty cool

[dvarsam]

This is pretty much unnecessary if the server version is used in a thin-client network. Only the server ever needs to get updated, the other computers just use the server's software.

Sure, but in the case that I don't want to use a Server & prefer a bunch of Desktops instead, at least I have a way to work around this...

In your scenario, you are forcing the user/company to use a Server, while my implementation is NOT!
At the same time, even though you might be right, you can still exclude Step 3 above, & point/target all the Clients to the Server's Repo instead!

Finally, you are also given a choice:
Instead of using the default Repo directory "/var/cache/apt/archives", you can use something like "/home/username/Repos"! This later one will be easier to visit compared to the Ubuntu's default one...

Not to mention, that Synaptic Package Manager is protected by a Password, and in the case of the Server-Client scenario of yours, a Client user won't have the Password to be able to tamper/change the settings added by the Administrator (regarding the Repos the Client PC is supposed to use)...

Thanks.

P.S.> One way or another, this is a better implementation from what we currently have!

[Tomosaur]

Sure, but in the case that I don't want to use a Server & prefer a bunch of Desktops instead, at least I have a way to work around this...

In your scenario, you are forcing the user/company to use a Server, while my implementation is NOT!
At the same time, even though you might be right, you can still exclude Step 3 above, & point/target all the Clients to the Server's Repo instead!

Finally, you are also given a choice:
Instead of using the default Repo directory "/var/cache/apt/archives", you can use something like "/home/username/Repos"! This later one will be easier to visit compared to the Ubuntu's default one...

Not to mention, that Synaptic Package Manager is protected by a Password, and in the case of the Server-Client scenario of yours, a Client user won't have the Password to be able to tamper/change the settings added by the Administrator (regarding the Repos the Client PC is supposed to use)...

Thanks.

P.S.> One way or another, this is a better implementation from what we currently have!

What you're talking about is a server, so what's the problem? You're just making the whole thing a bigger waste of resources. A server by definition is something which serves data / processes things for clients. Any version of Ubuntu can be used as a server, it's just that the server edition is intended for people who are comfortable with the command line. Your way requires:
a) More work
b) More, bigger hardware on each computer.

The current way only requires a decent server computer.

[sloggerkhan]

I think this is a great idea for home users with moderate bandwidth.
I don't know about business users or people with servers, but if I have 3 PCs or so running ubuntu at home and they share a fairly slow connection (say 100 kb or so), this could simplify things a lot and help keep bandwidth from being tied up when they update separately.

[runningwithscissors]

I thought this was common practice on lots of network setups.

Not to mention, it also allows for testing of the packages with the machines comprising the local infrastructure, and should be the preferred method for deploying anything on a private network.

[Polygon]

sounds like a great idea, but isnt this the same as just setting up an apt server on your company network or whatever? or is it different in some way (as in the apt server doesn't download the packages from the ubuntu repos then lets all the computers on the network upgrade them selfs from the apt server or something?

[Wolki]

You need something like nfs sharing on the computer that's supposed to serve the apt archives anyway, so why not just mount that directory to /var/cache/apt/archives on each computer?
I'd imagine a solution like this to have some issues though (what if two computers want to update at the same time?), so an apt-proxy or something similar is likely a much better solution, and shouldn't be difficult to install.

[mips]

What you're talking about is a server, so what's the problem? You're just making the whole thing a bigger waste of resources. A server by definition is something which serves data / processes things for clients. Any version of Ubuntu can be used as a server, it's just that the server edition is intended for people who are comfortable with the command line. Your way requires:
a) More work
b) More, bigger hardware on each computer.

The current way only requires a decent server computer.

Some just don't understand the definition of the word server... (and I'm not referring to you). Let it be.