Community VyOS builds organiztion

[mrlocke]

Hi!

Since VyOS Community forum is blocking further discussion about creating a community build infrastructure. I was wondering if we can create here or somewhere else a sharing point or forum.

And thanks a lot for working on this.

Let us know how can we help with resources or documentation.

[dd010101]

Hi,
I believe VyOS forum can be used for everything about VyOS with the exception of discussing development of related projects that don't necessarily align with the vision of VyOS team - like this one. That said this case is very specific and thus I don't believe you need forum just for this. That's why I think it make sense to discuss anything related to projects like this on GitHub.

The research about equuleus/sagitta repositories is done in sense it's possible to build equuleus/sagitta ISO with the result - so now it make sense that people test the instructions and the resulting image and report if it works for them as well.

I believe some people from community will host the infrastructure for others as well, some effort is already in progress. This would create community hosted repositories and thus it would enable the option to build ISO from stable branches as it was done before.

[dd010101]

I don't plan on removing VyOS branding since I don't think that's issue until you start to distribute ISO images and then it's a problem of the person who does the distribution, there is no link to this project. There is also issue that the more changes I make the more maintenance I will have. That's why I only make changes that are absolutely necessary to make it work. If someone wants to share ISO images then it's their duty to clean them of branding not ours.

If someone did maintain patch to remove branding what would be nice option to have for sure!

Good luck!

[GurliGebis]

I agree.
So far I have automated up until the set UID/GID part - I'm going to test if creating the jenkins user and group with the correct UID/GID before installing jenkins, to see if that works. (If it does, that would be a better solution, since permissions in the filesystem is stored by UID/GID, so changing it after installing might cause hidden issues)

[dd010101]

That's good point - for sure changing UID/GID can break things and will refuse to work if some process is already running under the UID. Not ideal.

If you could create it before apt does... I don't see why not unless the package has specific anti-collision mechanism, I guess most Debian packages will be fine with it but you need to test specific package to know... Let me know how it goes.

EDIT: actually the package needs to be fine with it, since if you uninstall Jenkins and install again, the user already exists from previous installation, the same happens on upgrade, so all Debian packages need to expect that user is already on system. Just make sure it has /var/lib/jenkins as home.

[dd010101]

I can confirm your idea works.

groupadd --system --gid 1006 jenkins
useradd --system --comment Jenkins --shell /bin/bash --uid 1006 --gid 1006 --home-dir /var/lib/jenkins jenkins

If I create group, user and apt install jenkins. Then Jenkins will use this user with correct UID/GID.

I also updated readme with this new instruction.

[GurliGebis]

Perfect, I'll copy/paste that into my install script 🙂
I hope to maybe get an hour or two this evening to work on it again. (You can check my fork of this repo, if you want to follow along - the branch is called ìnstall-scripts`)