XPost: linux.debian.maint.boot

On 07/08/2024 at 20:33, Holger Wansing wrote:

A recipe specific for server installations, which limits the swap to let's say 1G or 2G, because the machine has enough RAM built-in.

What would be the other partitions in this "server" recipe ?
- /var/log as suggested by José Ángel Pastrana ?
- /srv ?

limiting the swap size to the lower of
100% RAM size and ~5% (open to discussion) disk space.

Any opinions about this ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

Hi,

Am 8. August 2024 08:16:03 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

On 07/08/2024 at 20:33, Holger Wansing wrote:

A recipe specific for server installations, which limits the swap to let's >> say 1G or 2G, because the machine has enough RAM built-in.

What would be the other partitions in this "server" recipe ?
- /var/log as suggested by José Ángel Pastrana ?
- /srv ?

I think, a separate /srv and /var would be useful.

limiting the swap size to the lower of
100% RAM size and ~5% (open to discussion) disk space.

Any opinions about this ?

A good default IMO.



Holger



--
Sent from /e/ OS on Fairphone3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

Holger Wansing <hwansing@mailbox.org> writes:

Hi,

Am 8. August 2024 08:16:03 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

On 07/08/2024 at 20:33, Holger Wansing wrote:

A recipe specific for server installations, which limits the swap to let's >>> say 1G or 2G, because the machine has enough RAM built-in.

What would be the other partitions in this "server" recipe ?
- /var/log as suggested by José Ángel Pastrana ?
- /srv ?

I think, a separate /srv and /var would be useful.

limiting the swap size to the lower of
100% RAM size and ~5% (open to discussion) disk space.

Any opinions about this ?

A good default IMO.

Sorry for being late to the party.

I also think this looks a lot better than what we currently have.

While we're changing things, could we distinguish between LVM recipes
and non-LVM ones?

I tend to install servers with something like the multi recipe, except
instead of devoting the bulk of the disk to /home I instead leave it unallocated (which I do by allocating a spare volume, with keep set to
avoid wasting time formatting it, and I then remove in the late script).
That then gives the flexibility of easily adding volumes or extending
them, as needed by the system.

At present I'm doing that with this fragment of my preseed framework:

https://hands.com/d-i/preseed/classes/partition/_/unfilled/

but we could include this as a feature of D-I if people thought it was
useful, and could presumably implement it without needing to allocate
and then remove the spare bit as I'm doing at present.

The other thing I tend to when using multiple partitions is allocate
1.5GB to /boot so that there's enough room for a grml image for use in conjunction with the grml-rescueboot package.

Would it be worth making the upper limit for /boot be 1.5G, and using a
scaling factor (if possible) that will only use that much for disks
larger than 1TB, say, as then its a small enough proportion to be no
loss even if people don't use it for grml.

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAma2MB0ACgkQ0EujoAEl 1cAMRQ//Ucn+5ekrHq1M+QWMy0JBnI4HJeZauT3GmGYZhfB4PbRBWCAQh1SQaH07 LRmLoNdDeCb3nLUjRnCqkk3tNLhbooxahz+U24BS8LROPsHg0N61KzIkgjI0+AuJ 6a97WtWFaLspRr9dkFgKeiblFlf5ouy04AKSWpfUloP/SdvfH2xDUx4pOR2XWl0Z vq7tQUM53llq8v1FahsX85srfM1x7PHrZdLY0/5NqgPln2yl7rEjfMgceTWwud6M HiTsTyBGTDeO7uUtiPPnA/G2mmdXjkbGQ1Q2UY2e1c2otR2/p7dsLpY+D7f5S8Jl N0P95GG1GuRLK7P8gNwIaVocDoY9qFKg59TII2Fwt4LRkIE1WRno+siBWUvp9mqd V+RsDBSLnllD5KbkXu6oLGArTyHQqyGE41mvsDUm/jFHE1UglFIT2MIXBLUHp86V gxUmcezuWOrJx+2CPTu+HD4A98PmsKtv1pRsUxTb4USbrN8M0pfK22TQeTSm3flj 2mlWVlpw4FrrYztuFtDVt4qlmPFkP8zHXUrcDwmGEN2K6x4p2VNMrxAusdyYbZze AZBQo3SGRM6Vz9PL0J1zTrEiusLj0JM41VQ7/xHAp2lm62tnypuxeOcCQ0jkje26 pMJPYddpuLIvCT5o3F4ycNlt3eP2jZA5JNNhDJjnBx/YpvCv968=dgW7
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

XPost: linux.debian.maint.boot

On 09/08/2024 at 17:05, Philip Hands wrote:

While we're changing things, could we distinguish between LVM recipes
and non-LVM ones?

What would be the differences between LVM and non-LVM recipes ?

I do not see how to do this only in recipes, except by adding a dummy
partition with $lvmignore{ } or $defaultignore{ } and a minimum size
bigger than any storage capacity so that the recipe is rejected, which
is clearly a hack. A cleaner way would be that partman-auto and partman-auto-lvm look for built-in recipes in different locations.

I tend to install servers with something like the multi recipe, except instead of devoting the bulk of the disk to /home I instead leave it unallocated (which I do by allocating a spare volume, with keep set to
avoid wasting time formatting it, and I then remove in the late script).
That then gives the flexibility of easily adding volumes or extending
them, as needed by the system.

Guided partitioning with LVM already provides a feature to reserve space
in the VG. Maybe it could be extended to guided partitioning with plain partitions.

The other thing I tend to when using multiple partitions is allocate
1.5GB to /boot so that there's enough room for a grml image for use in conjunction with the grml-rescueboot package.

Isn't this a niche use case ? My understanding was that guided
partitioning was primarily intended for general purpose use cases.

Would it be worth making the upper limit for /boot be 1.5G, and using a scaling factor (if possible) that will only use that much for disks
larger than 1TB, say, as then its a small enough proportion to be no
loss even if people don't use it for grml.

It is at least possible. The PRIORITY value in recipes represents a
"scaling factor", in a rather convoluted way.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)