Installation on a large, specific structure

[Benjamin]

Good morning,

I'm getting back to you very late, but things are progressing at their own pace here.

Thanks to all your helpful advice, I was able to run my tests in VirtualBox without any problems, and I was able to give a presentation/demo to my superiors. They appreciated the tool and approved setting up an experiment before a potential real-world deployment.
Following this, we launched a test in an establishment condition and it works perfectly under the conditions mentioned above in previous posts (central server which serves as central repository, local repository in establishment for local groups and machines, and secondary repository synchronized with the central, clients configured for these 2 repositories).

I'm hopeful that I can arrange product training for my colleagues and myself, and even have a system implementation service in place, including services to migrate from SE3 to Samba4. But that's another matter, and before that, I still need to provide some additional information.

Therefore, following these "real-world" tests and requests from my superiors, I have some questions regarding the intended use:

• - Is there a way to create certificates in bulk (via the command line from the server, for example) so that they can be generated in advance for all sites, and then tell the local servers/consoles/clients to use these certificates rather than having to generate one during local console installation? I think so, but I'd prefer to ask you to get the command or some pointers.
  - Another very important question in our case: is there a way on the local servers of the institutions to prohibit the use of the "import from internet" and "import from file" functions to ensure that people authorized to use the consoles cannot retrieve "unauthorized" packages via the internet? I can see a way to only allow our repository through a firewall, but I would prefer that this function not be usable.
  - To confirm, the difference between using the central secondary repository and manually importing from it via the console is: In the first case, a package update will be automatically deployed to the facilities without human intervention once the rsync between the central and secondary repositories has been performed. Whereas in the second case, where the updated package is manually imported into a local console, it will not be updated because it is considered a new package with the local signature. Is that correct?
  - Also for confirmation, a lost certificate is permanently unrecoverable; in this case, a new one must be generated and all packages re-imported so that they adopt the new signature? (This seems obvious to me, but I would like confirmation.)

Thank you for your invaluable past and future help.
@micalement,

Benjamin

[sfonteneau]

Good morning,

I'm getting back to you very late, but things are progressing at their own pace here.

Thanks to all your helpful advice, I was able to run my tests in VirtualBox without any problems, and I was able to give a presentation/demo to my superiors. They appreciated the tool and approved setting up an experiment before a potential real-world deployment.
Following this, we launched a test in an establishment condition and it works perfectly under the conditions mentioned above in previous posts (central server which serves as central repository, local repository in establishment for local groups and machines, and secondary repository synchronized with the central, clients configured for these 2 repositories).

I'm hopeful that I can arrange product training for my colleagues and myself, and even have a system implementation service in place, including services to migrate from SE3 to Samba4. But that's another matter, and before that, I still need to provide some additional information.

Therefore, following these "real-world" tests and requests from my superiors, I have some questions regarding the intended use:

• Is there a way to create certificates in bulk (via the command line from the server, for example) so that they can be generated in advance for all sites, and then tell the local servers/consoles/clients to use these certificates rather than having to generate one during local console installation? I think so, but I'd prefer to ask you to get the command or some pointers.

We're using OpenSSL, so yes!

- Another very important question in our case: is there a way on the local servers of the institutions to prohibit the use of the "import from internet" and "import from file" functions to ensure that people authorized to use the console cannot retrieve "unauthorized" packages via the internet? I can see how to only allow our repository via a firewall, but I would prefer that this function not be usable.

Well, that's where it gets complicated, because not to my knowledge and it's not something standardized.
I've just been hired at tranquil.it and I know that the case you want to set up is in the works and I think we might be able to offer you something.

I suggest you contact Vincent Cardon from tranquil.it; he will be able to answer your question.

- To confirm, the difference between using the central secondary repository and manually importing from it via the console is: In the first case, a package update will be automatically deployed to the facilities without human intervention once the rsync between the central and secondary repositories has been completed. Whereas in the second case, where the updated package is manually imported into a local console, it will not be updated because it will be considered a new package with a local signature. Is that correct?

That's it!

- Also, for confirmation, a lost certificate is permanently unrecoverable; in this case, a new one must be generated and all packages re-imported so that they adopt the new signature? (It seems obvious to me, but I would like confirmation)

Yes, that's it!

Thank you for your invaluable past and future help.
Sincerely,

Benjam

[Benjamin]

Hello and thank you for your replies, which confirm what I thought.

Regarding OpenSSL, I'll take a closer look at the bulk generation of all certificates and the necessary procedures (copying them to private and SSL, I assume, and especially how to automate client deployment with this certificate) on remote consoles so they can use it.
We're not yet deploying it in our institutions, so there's no rush, but it's to prepare a small script in advance for when it's due.

Thank you also for the confirmations.

Regarding the issue of blocked import functions from other repositories, I'll contact Vincent again.
In any case, we (my superiors and/or I) need to contact him again soon about Samba4/WAPT/Package Creation, and I'll take the opportunity to ask for a solution to this problem, which could be a real obstacle to implementing this solution for my superiors.

Thanks again for your replies.
Best regards,

Benjam