Advice on Poudriere setup and workflow

CyberCr33p

CyberCr33p

Yesterday, I've set up a poudriere server to build packages for software used on other servers. These servers have software installed on the host as well as in various jails. In the host I run Nginx, MySQL, Dovecot, Postfix and PHP 8.1. In one jail I run PHP 8.3, in other jail I run ClamAV and in the last jail I run Valkey.

1) Is it better to create a separate poudriere jail for the host and individual poudriere jails for each of the jails?

2) Do you run poudriere ports -u to update the ports tree, or do you perform a git pull/gitup in /usr/ports and then use that with poudriere?
Since I’ve always used /usr/ports and don’t have much experience with pkg, do you keep the pkg.freebsd.org repository enabled, or do you disable it? If I disable it, that's fine as long as I don't try installing/upgrading software that wasn't built by poudriere, right?

3) Do you run poudriere builds automatically via cron, or do you execute them manually? I'm considering using cron, but I'm wondering what happens if a build hasn't finished by the time the next one starts. Do you use lockf or another mechanism to ensure that only one instance runs at a time?

4) On my other servers, after updating /usr/ports using gitup, I run pkg version -vL= to check if software needs updating. Now with poudriere packages, this requires me to run pkg update followed by pkg upgrade -n. Is there an alternative pkg command that simply shows whether newer software versions are available?

5) You recommend after each build to copy the packages from /usr/local/poudriere/data/packages/142amd64-default
to /usr/local/poudriere/data/packages/142amd64-default-$(date +%Y%m%d-%H%M) in case I need to rollback to previous software versions?
 
1) probably not. It's obviously easier if you can "match" everything, i.e. use the same PHP version everywhere. But for PHP it might be possible to simply build a specific PHP flavor for your web applications. Then you can still have everything in the same repository.

2) Yes, I use poudriere ports -u, I also have separate ports trees for desktop and server repositories. I sometimes want to test specific desktop or server patches, and don't want one to interfere with the other.
CyberCr33p said:
do you keep the pkg.freebsd.org repository enabled, or do you disable it?
Click to expand...
I disable the FreeBSD repositories and get everything from my own repositories.

3) Start it manually, but it's a script, it updates the ports trees then runs the various builds.
Code: 
#!/bin/sh

SERVER_REPOS="15-current 142-release 141-release 14-stable"
DESKTOP_REPOS="142-release 14-stable"

POUDRIERE=/usr/local/bin/poudriere

BASEDIR=/usr/local/etc/poudriere.d

${POUDRIERE} ports -u -p desktop
${POUDRIERE} ports -u -p server

for j in ${SERVER_REPOS}; do
  ${POUDRIERE} bulk -j ${j} -p server -f ${BASEDIR}/${j}-server-package.lst
done

for j in ${DESKTOP_REPOS}; do
  ${POUDRIERE} bulk -j ${j} -p desktop -f ${BASEDIR}/${j}-desktop-package.lst
done

#poudriere logclean -y 14

CyberCr33p said:
in case I need to rollback to previous software versions?
Click to expand...
Code: 
# Keep older package repositories. This can be used to rollback a system
# or to bisect issues by changing the repository to one of the older
# versions and reinstalling everything with `pkg upgrade -f`
# ATOMIC_PACKAGE_REPOSITORY is required for this.
# Default: no
#KEEP_OLD_PACKAGES=no

# How many old package repositories to keep with KEEP_OLD_PACKAGES
# Default: 5
#KEEP_OLD_PACKAGES_COUNT=5
/usr/local/etc/poudriere.conf

Rarely use this though, I just revert the updates in the ports tree then do a new build run.
 
SirDice said:
1) probably not. It's obviously easier if you can "match" everything, i.e. use the same PHP version everywhere. But for PHP it might be possible to simply build a specific PHP flavor for your web applications. Then you can still have everything in the same repository.
Click to expand...
Since I provide shared hosting, I need to support multiple PHP versions because customers use various software applications that require specific PHP versions to operate correctly.

If I'm running roundcube on the host with PHP 8.1, are you suggesting that instead of listing it as mail/roundcube in the pkg list, I should specify it as mail/roundcube@php81 ?
 
CyberCr33p said:
If I'm running roundcube on the host with PHP 8.1, are you suggesting that instead of listing it as mail/roundcube in the pkg list, I should specify it as mail/roundcube@php81 ?
Click to expand...
Yes. I was migrating from PHP 8.1 to 8.2 and just built both flavors:
Code: 
mail/roundcube@php81
mail/roundcube@php82

CyberCr33p said:
How you revert the updates in the ports tree? I see that poudriere ports -u doesn't support to load a previous git commit?
Click to expand...
Make sure poudriere checks out a "full" clone (not a shallow one). Then you can simply use git(1) on that ports tree to revert commits, change branches, etc.

Code: 
                    git[+protocol]  Use Git to download the sources.

                                    Sources will be cloned shallowly unless -D
                                    is specified.
poudriere-ports(8)
 
I'm using poudriere for stable/14 (not using for main [aka Current] as frequent OSVERSION bump matters) and as I wanted to share as much as possible with bare-metal builds (i.e., kmods need to be rebuilt on kernel updates), I maintain ports tree at default /usr/ports/ and null mount it for poudriere builder(s), thus, not at all using poudriere ports.
And sharing saved options in /var/db/ports/ by symlinking.

I'm sharing my conifguration at brew.bsd.cafe.
Wouldn't 100% match for your use-case (I don't have web server installed, thus, using local repo URL starting with file://), but would be of some hints.
 
And one last question:

I changed /usr/local/etc/poudriere.d/make.conf and removed "DEFAULT_VERSIONS+=ssl=openssl111". In the next build run shouldn't rebuild all ports that depend on openssl? Because I think that it doesn't rebuild them. If poudriere doesn't detect this change how can I force rebuild the ports that depend on openssl (or rebuild all ports)?
 
I think the -c option does the rebuild of all ports: poudriere bulk -j server -p default -f /usr/local/etc/poudriere.d/server-pkglist.txt -c
 
CyberCr33p said:
And one last question:

I changed /usr/local/etc/poudriere.d/make.conf and removed "DEFAULT_VERSIONS+=ssl=openssl111". In the next build run shouldn't rebuild all ports that depend on openssl? Because I think that it doesn't rebuild them. If poudriere doesn't detect this change how can I force rebuild the ports that depend on openssl (or rebuild all ports)?
Click to expand...
Possibly poudriere does not (properly) aware of DEFAULT_VERSIONS.
Not 100% sure in this case, but possibly deleting openssl111 package from poudriere pkg repo would invoke anything depending on it. And hopefully rebuild themselves pick the DEFAULT_VERSION removal. If not, try intentionally set DEFAULT_VERSIONS+= ssl=base, it should be defaut, though.

By the way, do you have /etc/make.conf and it contains DEFAULT_VERSIONS+= ssl=openssl111 line? If so, poudriere would think you want openssl111 as SSL implementation, if not explicitly overridden.
 
/etc/make.conf doesn't contain DEFAULT_VERSIONS+= ssl=openssl111 but I think it's not used. I believe only /usr/local/poudriere.d/make.conf copied and used in poudriere build jails.
 
CyberCr33p said:
/etc/make.conf doesn't contain DEFAULT_VERSIONS+= ssl=openssl111 but I think it's not used. I believe only /usr/local/poudriere.d/make.conf copied and used in poudriere build jails.
Click to expand...
Ah, sorry, looks yes now.
Not sure when the behavior changed, but before, I saw make.conf is read twice in logs. (I have symlink named make.conf pointing to /etc/make.conf in /usr/local/etc/poudriere.d/.) But ongoing build logs contained only once.
 
And another question:

In the pkglist.txt I had databases/phpmyadmin5 and changed it to databases/phpmyadmin5@php81 and rerun the build:

Now the packages directory has:

phpMyAdmin5-php81-5.2.1_1.pkg
phpMyAdmin5-php83-5.2.1_1.pkg

Do I have to manually delete phpMyAdmin5-php83-5.2.1_1.pkg or is a poudriere command to remove packages that are not needed?
 
I setup a server to test the switch from ports to pkg. So, I pkg upgrade and now if I run pkg autoremove it shows 45 packages to be removed but these packages are needed. Any idea why this happens? The ports options in poudriere are the same as /var/db/ports
 
CyberCr33p said:
I setup a server to test the switch from ports to pkg. So, I pkg upgrade and now if I run pkg autoremove it shows 45 packages to be removed but these packages are needed. Any idea why this happens? The ports options in poudriere are the same as /var/db/ports
Click to expand...
I just notice that I had options in /usr/local/etc/poudriere.d/142amd64 instead of /usr/local/etc/poudriere.d/142amd64-options or /usr/local/etc/poudriere.d/options so they are build with the default options. I will rename the directory and retry.
 
CyberCr33p said:
I setup a server to test the switch from ports to pkg. So, I pkg upgrade and now if I run pkg autoremove it shows 45 packages to be removed but these packages are needed. Any idea why this happens? The ports options in poudriere are the same as /var/db/ports
Click to expand...
A wild prediction would be currently installed ports are somehow recorded as "automatic".
If this is the case, an old thread pkg - promote Automatic package to Manual would help.
 
CyberCr33p said:
I just notice that I had options in /usr/local/etc/poudriere.d/142amd64 instead of /usr/local/etc/poudriere.d/142amd64-options or /usr/local/etc/poudriere.d/options so they are build with the default options. I will rename the directory and retry.
Click to expand...
As described in my already-mentioned page, if you want the options that are already saved in /var/db/ports to be used by poudriere,
Code: 
ln -s /var/db/ports /usr/local/etc/poudriere.d/options
would help.
 
CyberCr33p said:
I use poudriere in a different server than the servers that the packages used. Thank you.
Click to expand...
If the build server had been used for building packages with something other than poudriere (i.e., pkg_replace with -p option or make package) and using them on other servers, /var/db/ports would have already-used options.
But if not, yes, there should be none.

Another rough but convenient way would be (if previously each servers build ports that it needs) copying existing configurations from /var/db/ports in each servers to /var/db/ports in the build server (beware of conflicting configs!).
 
T-Aoki said:
Another rough but convenient way would be (if previously each servers build ports that it needs) copying existing configurations from /var/db/ports in each servers to /var/db/ports in the build server (beware of conflicting configs!).
Click to expand...
That's exactly what I did.
 
You must log in or register to reply here.
Back
Top