| amesser | Hi Leepen! Long time no see :-) | 12:19 |
|---|---|---|
| amesser | I have to prepare some security updates for tomcat9 beowulf and chimaera | 12:20 |
| amesser | I finished with beowulf, woult need build of suites/beowulf-security branch | 12:21 |
| amesser | However, when preparing for chimaera, i found that I messed tomcat9 version for chimaera | 12:21 |
| amesser | bullseye has 9.0.43-2~deb11u1 while chimaera is already 9.0.43-3 | 12:23 |
| amesser | I researched and found, that 9.0.43-3 was uploaded to unstable while its precedessor, 9.0.43-2, was never uploaded anywhere, instead 9.0.43-2~deb11u1 was uploaded to testing/bullseye. | 12:25 |
| amesser | Im a bit confused about the versions numbers, because in Debian's changelog file for bullseye we have "9.0.43-2" (never uploaded) then "9.0.43-2~deb11u1" (uploaded and avail), and finally "9.0.43-2~deb11u2" (uploaded / on its way to repos) | 12:27 |
| amesser | But from Debian policy manual 9.0.43-2~* will sort before 9.0.43-2. So if you would have installed 9.0.43-2, you would never get updates through apt? Just comparing versions, bullseye changelog for tomcat9 has wrong order. I don't understand why they use the tilde there (instead of '+') | 12:30 |
| amesser | However, my prosoal to handle this, is to merge debian updates into our 9.0.43-3+devuan... versions. Otherwise a downgrade would be required. | 12:32 |
| LeePen | amesser: I agree it is confusing and convoluted! | 13:40 |
| LeePen | I think the bullseye versions work because 9.0.43-2 was never in the suite. | 13:43 |
| LeePen | On [2021-08-09] when the security fix was backported to testing (during the freeze), 9.0.43-2 was in unstable | 13:44 |
| LeePen | so .0.43-2~deb11u1 was the correct version to pick. | 13:44 |
| LeePen | That ensured that if there were never any further uploads, upgrades in the future would still work. | 13:44 |
| LeePen | I think your proposal for Devuan versions is right for unstable/chimaera. | 13:46 |
| LeePen | We have to get the versions to work from where we are. | 13:49 |
| amesser | Hmm, but in the changelog file for bullseye, there is 9.0.43-2 and then above 9.0.43-2~deb10u1. If you would use a script which would order the changelog file based on version numbers. It would reverse that. | 13:49 |
| LeePen | Hope that is clear? | 13:49 |
| amesser | Yep, fine I'll go on for 9.0.43-3+devuan2 then for chimaera | 13:50 |
| amesser | It just confused me bit since i would expecte the changelog to appear in same order as defined by debian policy. | 13:51 |
| LeePen | I think you see that in other changelogs where there is a backport or similar. The order is by date rather than strictly by version. | 13:51 |
| amesser | Hmm. But apt would look on version number only? | 13:51 |
| LeePen | The backport version is designed to be lower to facilitate future upgrades. | 13:52 |
| LeePen | Yes apt and dpkg do, but in this case | 13:52 |
| amesser | So everything just only works becaus 9.0.43-2 has never been uploaded ( and would never) | 13:52 |
| LeePen | 9.0.43-2 was never in bullseye, only unstable. | 13:52 |
| amesser | no, it was not in unstable as well | 13:53 |
| LeePen | [2021-08-07] Accepted tomcat9 9.0.43-2 (source) into unstable (Markus Koschany) | 13:53 |
| amesser | arg, missed that | 13:53 |
| amesser | But regarding backports, these usually have higher version numbers before "~" than the non-bpo version of the same suite. | 13:56 |
| amesser | Anyway, doesn't matter. Maybe i'm a bit picky about that, but I dislike such inconsistencies - physicists like symmetry | 13:58 |
| LeePen | But this wasn't a backport as such, it was a way of getting a security fix into bullseye during the freeze. | 13:58 |
| amesser | Hmm, I think I got it now. | 13:59 |
| LeePen | I always find these sort of versioning things mind bending! | 13:59 |
| amesser | Still the changelog file, grrr. I understand, 9.0.43-2 was never meant to be part of "bullseye" | 14:00 |
| amesser | Just forget about it. | 14:00 |
| amesser | So, if you like, you could be triggering a build for tomcat 9 suites/beowulf-security | 14:01 |
| amesser | This is already uploaded to gitea. | 14:01 |
| amesser | chimaera-security will follow soon | 14:01 |
| amesser | Or is there a way I can trigger? | 14:01 |
| LeePen | Done. | 14:05 |
| amesser | thx. | 14:05 |
| amesser | just pushed suites/chimaera-security as well | 14:06 |
| amesser | I can push updates to "unstable" as usual and trigger by myself? It wont end up in chimaera? | 14:06 |
| LeePen | Unstable is migrating to daedalus now. | 14:09 |
| amesser | ok, fine | 14:10 |
| amesser | again, many thx. sorry for bothering you | 14:10 |
| LeePen | It is fine. | 14:11 |
| LeePen | I will hold off building chimaera for now until unstable is built. | 14:13 |
| amesser | ok. I'll get back to you when this is made. (not before this evening) | 14:14 |
| LeePen | Thanks. | 14:14 |
| amesser | exit | 15:02 |
| amesser | lol | 15:02 |
| LeePen | Bye! | 15:03 |
| bgstack15 | Team, does the Devuan 4.0 Chimera amd64 netinstall iso, under expert mode, no longer support guiding the user through setting up encrypted LVM? | 18:36 |
| bgstack15 | Or LVM at all, in the TUI? | 18:36 |
| rwp | Has anything in that part of the installation changed? I didn't think so. | 18:41 |
| bgstack15 | I recall being able to set up LVM and even LUKS from the TUI for previous versions of Devuan. | 18:47 |
| rwp | I am pretty sure that is still all the same as it has been for a long time. I'll run through a VM install and peek at the current state of things... | 18:55 |
| rwp | bgstack15, Install walk through with images: https://www.devuan.org/os/documentation/install-guides/chimaera/full-disk-encryption.html | 19:00 |
| bgstack15 | Yes, I am doing that now with my old Devuan 3.0 netinstall media. Maybe perhaps the lvm/encrypted-lvm stuff just doesn't get enabled in the "expert mode" of the netinstall? | 19:01 |
| rwp | That's possible and/or likely. Because... expert-mode after all. | 19:05 |
| rwp | I am about halfway through the basic install and it was just as the documentation above described. I'll reset it when done and run through an expert mode install... | 19:05 |
| rwp | I ran through the Expert Mode installation and the "Guided - use entire disk and set up encrypted LVM" option was presented the same as in basic mode. | 19:22 |
| rwp | It was all the same for Expert Mode as described in https://www.devuan.org/os/documentation/install-guides/chimaera/full-disk-encryption.html | 19:23 |
| rwp | Other than offering some additional options such as specifying the vg name and so forth. | 19:23 |
| bgstack15 | which iso? | 19:28 |
| bgstack15 | and hm, maybe I picked options in the wrong order or partman-lvm didn't load. | 19:29 |
| bgstack15 | It also wasn't offering me ext3 or ext4 either, so something was pretty screwy. | 19:29 |
| rwp | I used the devuan_chimaera_4.0.beta-20211004_i386_netinstall.iso from last week. | 19:35 |
| rwp | I'll update to the current release. | 19:36 |
| bgstack15 | I was using http://files.devuan.org/devuan_chimaera/installer-iso/devuan_chimaera_4.0.0_amd64_netinstall.iso with sha256sum of 0923470af430e3d582a635956bbe4c13abc18fbaa4704e6deef3b362833e0ef5 | 19:40 |
| golinux | You forgot to load something about "components" | 19:59 |
| golinux | This is documented on the forum | 19:59 |
| golinux | It is an option somewhere in the process | 20:00 |
| golinux | https://dev1galaxy.org/viewtopic.php?id=4038 | 20:01 |
| golinux | "load components" is what you missed | 20:02 |
| golinux | bgstack15: ^^^ | 20:02 |
| rwp | At that ref doc at step 8) one can change the file systems at the review stage. | 20:04 |
| bgstack15 | Thank you, golinux! I fully expect I had missed one of the menu options. I'm progressing with my Devuan 3.0 install at this point, and will just convert it to Ceres like I always do, but I will try to remember this for next time, which will happen very soon. | 20:05 |
| golinux | Happy I could remember that. It has been brought up several times in the last weeks | 20:07 |
| golinux | Remembering is always the challenge and it doesn't get any easier . . . :D | 20:08 |
| golinux | rrq: Here's a thought . . . Since there have been so many users missing "load components", I'm wondering if perhaps it was checked by default on previous installation media. | 20:14 |
| bgstack15 | Well, in my case it would have been because I failed to choose the "load components" menu entry on the expert install. I would have just overlooked it or guessed it had been run, because choosing one menu item sometimes picks multiple. | 20:25 |
| rwp | I didn't notice because I always walk through every one of those sub menus accepting the defaults unless I want to customize them. | 20:30 |
| systemdlete | bgstack15, rwp: I have successfully installed chimaera using netinstall in expert mode and got multiple LVs encrypted in the install process | 20:56 |
| systemdlete | I did not have to "load components" (I think you are talking about the step earlier in the install where it asks you if you want any of the additional packages?) | 20:58 |
| systemdlete | Not sure if there is an "order" you have to follow, but I do note that there are a few pitfalls if you are not careful. | 20:59 |
| systemdlete | For one thing, I found that if I repartition the disk during the install, that can cause problems. In my case, I started out with 2 primary partitions of the hard disk, then decided to go with only one. So I would have only 1 PV rather than 2 PVs. | 21:00 |
| systemdlete | But that caused problems much later when I quit the whole partitioning step -- the installer was unable to mount the root partition I had designated. After that, it was endless looping through the steps of the partitioning. | 21:01 |
| systemdlete | Ultimately, I decided to reboot the whole thing and start over again. It is a tedious process each time (is there a way to store the state of the install to a thumb drive or the like and restore it after rebooting the target?) | 21:02 |
| systemdlete | So I had to go through all of the steps again. But because I did not make any "mistakes" (change my mind about disk partitions as I had the first time), I was able to go through the partitioning without any problems this time. The installer was able to mount all of my partitions and successfully comlete the whole install. | 21:03 |
| systemdlete | To recapitulate, I would say it is probably best to have a clear idea of your partitioning plan BEFORE you begin the partitioning step. The installer tool is not forgiving about second takes. At least, this has been my experience. | 21:05 |
| systemdlete | One other thing to note is that if you want to have multiple encrypted LVs, the install does not combine the passwords for them, even if they are the same. After the install completes and you reboot the new system, you have to go into the crypttab file and arrange for a single key to be input at boot time. | 21:07 |
| systemdlete | (Although, actually, if you shell out right after the installer completes and asks you to reboot the new system, you could likely do it there also, idk) | 21:07 |
| systemdlete | for this procedure, you have to install a package, modify the crypttab, and run initramfs. After that, it was prompting me only one time for encrypted LV password at boot time. | 21:08 |
| systemdlete | So what rwp is trying to do is not only possible, but quite doable. | 21:09 |
| rwp | s/rwp/bgstack15/ I think you wanted there. :-) | 21:10 |
| systemdlete | oops | 21:10 |
| rwp | Can't tell the players without a program! Get your theater programs here. Programs. Who wants a program. :-) | 21:11 |
| systemdlete | :p | 21:11 |
| systemdlete | (and so here I am, TRYING to help these poor souls...) | 21:11 |
| rwp | Me too! And you are doing a fine job of it. :-) | 21:12 |
| systemdlete | thanks | 21:12 |
| rwp | I have also seen problems where redoing a partition step can confuse the partitioning process. And it is easier to reboot and start again rather than try to shape it differently. | 21:13 |
| systemdlete | thanks for confirming that point, rwp | 21:13 |
| rwp | For encryption I only ever set up one PV to be encrypted and therefore only manage one passphrase for it. | 21:14 |
| systemdlete | I think the single biggest problem is that there is no easy way to force the install process to re-read the partition table. I could not get access to any of the usual tools for that. | 21:14 |
| systemdlete | rwp: That is fine if you are using some sort of qcow disk. But I have avoided them with vbox since about version 4 or 5 after being advised not to use them. | 21:15 |
| rwp | I think it is possible to back everything out. But one needs to tediously back everything out one step at a time in reverse order. Reversing the steps manually many of which were done automatically by the scripts. | 21:15 |
| systemdlete | Probably. But like you said -- and I agree -- it is easier to just reboot and start over. The energy expended in backing out each partition and all is more than it takes to go through the install from start to the partitioning step, IMO. | 21:17 |
| rwp | Actually I was agreeing with your statement that it was easier to reboot and start over. Though I think it is technically possible to recover manually. It's just very tedious. | 21:17 |
| systemdlete | extremely tedious, yes | 21:18 |
| rwp | Hmm... I only *use* encrypted partitions on real hardware, primarily laptops. I *test* encryption on KVM VMs. I don't normally encrypt PVs as a way to encrypt VMs for my production use. | 21:18 |
| systemdlete | well, the entire partitioning step is unduly tedious, imo | 21:18 |
| rwp | For VMs it really all depends upon how one wants to manage their storage. That's at least a handful of chapters in a manual that we wished existed for it. | 21:19 |
| rwp | Here for persistent "production running" VMs I allocate an LV for them. They each get their own LV partition. It's good performance that way. | 21:20 |
| systemdlete | I find the dynamic (rather than fixed) virtual disks in vbox to be much slower than preallocated (fixed) size disks | 21:20 |
| rwp | For test VMs I use qcow2 as those are elastic in size, easy to use, and easy to manage. | 21:20 |
| systemdlete | so one PV per LV? | 21:20 |
| rwp | On a laptop for encrypted everything one /boot outside of the PV and one PV for 100% of the remaining. Into one VG. And allocate one LV for all on a laptop. Elsewhere LVs as desired. | 21:21 |
| systemdlete | oh, yeah. for testing purposes, cow disks are fine (although I still don't use them even for testing) | 21:21 |
| systemdlete | I put /usr on an UNencrypted LV, for speed. | 21:22 |
| systemdlete | and of course /boot too | 21:22 |
| systemdlete | but for /boot, obviously it is not really about speed so much. | 21:23 |
| rwp | I can't really complain about performance even on my old and rather mediocre performance Thinkpad x201 with everything encrypted. It's fine. | 21:23 |
| rwp | Newer faster cpu machines make the difference even less of a difference. | 21:23 |
| rwp | The biggest lever on performance really will be the amount of RAM available. More ram means more available for file system buffer cache, and therefore less actual I/O. | 21:24 |
| systemdlete | (less swapping) | 21:25 |
| rwp | Uhm... It's really _before_ the system gets into memory resource stress before even thinking about swapping. | 21:26 |
| rwp | Having enough file system buffer cache allows running at mostly RAM speeds. | 21:26 |
| rwp | If the kernel needs the RAM for userland process space then the first thing to go is file system buffer cache space. It will be reduced and then without the cache real I/O is required. Slow. | 21:26 |
| systemdlete | Recently, I discovered that a VM which was doing a lot of swapping was bogging the hardware down. So I disabled the swap in that VM and it has been running fine and the hardware is not bogged down as much. | 21:27 |
| rwp | After that is no longer enough *then* swapping will start and that will slow things down more. | 21:27 |
| rwp | I am trying to understand that statement. Because honestly if the system needs to swap and there isn't swap space then by default with Linux memory overcommit the OOM Kill will be required to start killing things. | 21:28 |
| systemdlete | I'm still trying to understand it myself. | 21:28 |
| rwp | Therefore I don't understand how a system that was in swap thrash mode could run without swap and also without the OOM Killer killing things. | 21:28 |
| systemdlete | I still have the swap turned off in that VM. | 21:28 |
| systemdlete | my bad, rwp. YOu are right. | 21:29 |
| rwp | Swap space is just a way to free up RAM for other purposes making RAM available by stashing unused things in swap for a while. | 21:30 |
| systemdlete | I have rebooted since then. swap is enabled | 21:30 |
| systemdlete | Oh, I know all about that. I just wasn't thinking just then... | 21:30 |
| systemdlete | atm,though, there is not much disk activity (per LEDs) | 21:31 |
| rwp | It's all good! | 21:31 |
| * systemdlete admits that was really dumb of him | 21:32 | |
| rwp | But I must still point out that swap thrashing does not occur just by having swap available. | 21:32 |
| rwp | It's like having a spare room in the house. Just having the room does not fill it with junk. And then move things in out and of that room all of the time. | 21:32 |
| rwp | Renting the spare room out to someone, and cleaning it out of our junk so that is possible, does not get rid of the junk by itself. | 21:33 |
| rwp | It just means there is no longer a spare room to stash it conveniently. | 21:33 |
| rwp | Swap thrashing occurs due to the set of processes running on the system that use it. | 21:33 |
| systemdlete | Most of the time, I find that swap is not used much on most of my systems. It's just that one VM that tends to fill up... endlessly. I use it for reading comic books and stuff, and those use a lot of it | 21:33 |
| rwp | The web and web browsers today are pigs! Sites use massive amounts of Javascript and huge images (often displayed small) taking up massive resources. | 21:34 |
| systemdlete | And it already has more memory allocated to it than any of the others, except one. | 21:34 |
| systemdlete | OH I KNOW. Tell me about it. | 21:35 |
| rwp | I think today a minimum size desktop required 8GB of RAM for the minimum. And I would start shopping for new at 16GB. Just for a basic DE. More if they want to do more. | 21:35 |
| rwp | But at the same time on my desktop I am not recompiling the repository. I would do that on a larger server system. And then suspend my laptop and relocate to a different coffee shop. | 21:36 |
| systemdlete | I have 32G on this machine. I usually allocate only 2G for most VMs, which is plenty -- they run fine. But I have one or two that need much more. I have one that gets about 6G. | 21:36 |
| systemdlete | I have ~150 down over cable/fiber here. (It's fiber in the street, then cable from the pedestal to the residence, in most of the US I think) | 21:37 |
| systemdlete | So I don't get bogged down by the connection too often. | 21:38 |
| amesser | LeePen: I just started tomcat9 build for unstable. Will take some time to finish. | 23:10 |
| amesser | However, time to sleep, bye! | 23:10 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!