Re: [CentOS] CentOS Stream suitability as a production webserver
On 07/01/2021 09:47, Jamie Burchell wrote: Didn't the CentOS Vault repo ensure that every package ever published was still available? Yes, it did, but that is not the intention for CentOS Stream moving forward. Only packages in CentOS Linux are moved to the vault at point release time. CentOS Stream only ever has the LATEST package version and nothing else. There is a bug filed for this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1908047 If it is likely to be an issue for you, please make that known. The more people this affects, the more likely it may be addressed. On 7 Jan 2021, at 07:03, Gordon Messmer wrote: On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote: - No chance to "yum history undo last" as there are no older packages I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense. In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback". In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback". It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
> On Jan 7, 2021, at 3:47 AM, Jamie Burchell wrote: > > Didn't the CentOS Vault repo ensure that every package ever published was > still available? > You should come to realizing that things changed. They are not what they were. With all fairness no one can say what will be true in a short future to come. Valeri >> On 7 Jan 2021, at 07:03, Gordon Messmer wrote: >> >> On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote: >>> - No chance to "yum history undo last" as there are no older packages >> >> >> I've seen that mentioned as a change pretty frequently, but I don't think it >> is in any meaningful sense. >> >> In CentOS Stream, package versions may be rebased periodically, and the >> public repos will no longer have older packages to install when using "undo" >> or "rollback". >> >> In CentOS, package versions may be rebased at minor releases, and the public >> repos will no longer have older packages to install when using "undo" or >> "rollback". >> >> It's true that you might be able to roll back a simple patch in CentOS in >> between minor releases, but those are the updates that everyone seems to >> regard as being the safest, and least likely to cause problems, and >> therefore the least likely to need undo/rollback. The only rational >> conclusion I can come to is that it doesn't matter if you're talking about >> CentOS today or Stream in the future: If you want to be able to roll back, >> you need a private mirror that keeps the package versions that you use. If >> you don't want a mirror, then you need to build, test, and deploy complete >> images rather than making incremental changes to mutable systems. None of >> this is new, it's always been this way and people have just accepted it. >> >> ___ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rare but repeating system crash in C7
Seems to be. Thanks again! Fred On Thu, Jan 7, 2021 at 1:46 AM Simon Matter wrote: > Hi Fred, no I was asking about the auto mount and umount issue you had. > Did you get it to work correctly? > > Simon > > > Simon, if you're talking about the occasional crash, I don't know, since > > it > > happens only occasionally. If I can make it thru six months without > seeing > > it, then I'll declare it fixed. > > > > Thanks! > > > > On Wed, Jan 6, 2021 at 1:23 PM Simon Matter > > wrote: > > > >> Have you been able to fix the issue? > >> > >> Regards, > >> Simon > >> > >> > OK, here's where I stand now: > >> > 1. I stopped and disabled autofs. (I have 2 SMB filesystems out on the > >> LAN > >> > that have also been automounting with autofs, do I need to do similar > >> > changes in fstab for them?) > >> > 2. yes it has. > >> > 3. none I can see. > >> > 4. nothing that leaps out at me. there are a couple about /mnt/backup > >> not > >> > existing but they appear to be old ones, aren't happening anymore. > >> > > >> > So, I've made a minor tweak to /etc/fstab, nothing that should matter. > >> > rebooted, and when it comes up /mnt/backup is mounted. TWICE, > >> according > >> to > >> > the output of mount: > >> > > >> > $ mount | grep backup > >> > systemd-1 on /mnt/backup type autofs > >> > > >> > (rw,relatime,fd=25,pgrp=1,timeout=900,minproto=5,maxproto=5,direct,pipe_ino=9840) > >> > /dev/sdc1 on /mnt/backup type ext4 > >> > (rw,relatime,seclabel,stripe=8191,data=ordered) > >> > > >> > is this really a double mount, or is this what I'm supposed to be > >> seeing? > >> > > >> > doesn't seem to timeout and auto umount. > >> > > >> > Thanks again for your assistance! > >> > > >> > Fred > >> > > >> > On Mon, Jan 4, 2021 at 7:48 AM Strahil Nikolov via CentOS > >> > > >> > wrote: > >> > > >> >> Verify that: > >> >> 1. Autofs is not running > >> >> 2. Systemd has created '.mount' and '.automount' units > >> >> systemctl status mnt-backup.mount mnt-backup.automount > >> >> systemctl cat mnt-backup.mount mnt-backup.automount > >> >> > >> >> 3. Verify that there are no errors in local-fs.target > >> >> systemctl status local-fs.target > >> >> > >> >> 4. Check for errors via: > >> >> mount -a > >> >> journalctl -e > >> >> > >> >> Best Regards > >> >> Strahil Nikolov > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> В понеделник, 4 януари 2021 г., 01:29:25 Гринуич+2, Fred < > >> >> fred.fre...@gmail.com> написа: > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> OK, I think I've got it set up as described here, while fixing the > >> >> misplaced fields in /etc/fstab: > >> >> > >> >> UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backupext4 > >> >> x-systemd.automount,x-systemd.idle-timeout=15min,noauto 0 2 > >> >> > >> >> now when I do, e.g., "ls /mnt/backup" > >> >> > >> >> I get: > >> >> > >> >> $ sudo !! > >> >> sudo ls /mnt/backup > >> >> ls: cannot open directory /mnt/backup: No such file or directory > >> >> > >> >> if I do: > >> >> > >> >> ls /mnt > >> >> > >> >> I see: > >> >> > >> >> backup > >> >> > >> >> use su to become root, then: > >> >> ls -l /mnt shows: > >> >> > >> >> # ls -al > >> >> total 4 > >> >> drwxr-xr-x. 3 root root0 Jan 2 13:24 . > >> >> dr-xr-xr-x. 21 root root 4096 Jan 2 09:22 .. > >> >> dr-xr-xr-x. 2 root root0 Jan 2 13:24 backup > >> >> > >> >> ls backup shows: > >> >> > >> >> # ls -al backup > >> >> ls: cannot open directory backup: No such file or directory > >> >> > >> >> why? it clearly appears to exist > >> >> > >> >> the FS isn't mounted, but /mnt/backup exists, so it should be visible > >> as > >> >> an > >> >> entry directory. also, I can mount it manually: > >> >> > >> >> mount UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup > >> >> > >> >> and then access it. but it doesn't automount with, e.g. "ls > >> /mnt/backup" > >> >> or > >> >> "ls /mnt/backup/backups". > >> >> > >> >> I must still be doing something wrong but maybe I'm too stupid to see > >> >> it. > >> >> (Please don't agree with me publicly...! :=) ) > >> >> > >> >> Fred > >> >> > >> >> On Sun, Jan 3, 2021 at 4:36 PM Pete Biggs wrote: > >> >> > >> >> > > > >> >> > > I commented out those entries in /etc/auto.master before > >> modifying > >> >> the > >> >> > > fstab entry: > >> >> > > > >> >> > > UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup > >> >> > > ext4,x-systemd.automount,x-systemd.idle-timeout=15min noauto 0 > >> >> 2 > >> >> > > >> >> > That's not correct. See 'man fstab'. It should be > >> >> > > >> >> >device mount-point filesystem-type options dump fsck > >> >> > > >> >> > So you should have: > >> >> > > >> >> > UUID=259ec5ea-e8a4-465a-9263-1c06217b9aaf /mnt/backup ext4 > >> >> > x-systemd.automount,x-systemd.idle-timeout=15min,noauto 0 2 > >> >> > > >> >> > > >> >> > > > >> >> > > which is exactly as it was before except for the x-systemd > >> entries > >> >> as > >> >> you > >> >> > > described. > >> >> > > >> >> > Yeah, you put them in the
Re: [CentOS] CentOS Stream suitability as a production webserver
Didn't the CentOS Vault repo ensure that every package ever published was still available? > On 7 Jan 2021, at 07:03, Gordon Messmer wrote: > > On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote: >> - No chance to "yum history undo last" as there are no older packages > > > I've seen that mentioned as a change pretty frequently, but I don't think it > is in any meaningful sense. > > In CentOS Stream, package versions may be rebased periodically, and the > public repos will no longer have older packages to install when using "undo" > or "rollback". > > In CentOS, package versions may be rebased at minor releases, and the public > repos will no longer have older packages to install when using "undo" or > "rollback". > > It's true that you might be able to roll back a simple patch in CentOS in > between minor releases, but those are the updates that everyone seems to > regard as being the safest, and least likely to cause problems, and therefore > the least likely to need undo/rollback. The only rational conclusion I can > come to is that it doesn't matter if you're talking about CentOS today or > Stream in the future: If you want to be able to roll back, you need a private > mirror that keeps the package versions that you use. If you don't want a > mirror, then you need to build, test, and deploy complete images rather than > making incremental changes to mutable systems. None of this is new, it's > always been this way and people have just accepted it. > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
