Hi all,
Reminder - the deadline to submit any self-contained changes you wish to
propose for Fedora Linux 45 is tomorrow, 21 July 2026.
Kindest regards,
Aoife
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
We put Anubis in place on a lot of our infrastructure to block
scrapers. I forget how long ago it was, but long enough for us to see
before/after and determine if it's helpful. So...is it?
I just read a post[1] from someone who had their AI agent trivially
work around it. I know I've had a few times where Anubis had a false
positive. I'm willing to put up with that if we're seeing a reduced
load from scrapers. I haven't seen any discussion about how well
Anubis is serving our needs, although it's entirely possible that I
just missed it.
[1] https://fzakaria.com/2026/07/09/who-does-anubis-actually-stop
--
Ben Cotton (he/him)
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/User:Bcotton
Hi everyone,
with the https://forge.fedoraproject.org/infra/ansible/pulls/3471 merged,
the original copr/certbot role has been moved to the top `roles` dir of the
ansible repo. All references have been updated and the role itself was left
unchanged.
However, if you are using it, I still want to give you a heads up just in
case.
--
Jiri Podivin
Senior Software Engineer, Openstack
Red Hat Czech, s.r.o. <https://www.redhat.com/>
Purkyňova 3080/97b
61200 Brno, Czech Republic
jpodivin(a)redhat.com M: +420739108412
IRC/slack: jpodivin
<https://red.ht/sig>
After I seen the talk about VDO:
https://www.youtube.com/watch?v=7CGr5LEAfRY
I went ahead and tried it.
I tried it on small (12GB) sample of Copr data and I saved 20-30% data.
I then deployed it on production server retrace.fedoraproject.org and saved there 15% out of 2TB.
Several notes: The RPM packages are only available for RHEL. Recently the public github has been updated with version of
VDO, which should work on Fedora. No RPM available for Fedora yet though.
Here are my notes:
# vdo create --name=vdo1 --device=/dev/vdb --vdoLogicalSize=1T
# mkfs.ext4 /dev/mapper/vdo1
Some slides suggest to use -E discard. This is not needed for new volumes. See vdo-devel mailing list for reasoning.
# mount -o discard /dev/mapper/vdo1 /mnt/a
Probably best scenario is to create vdo on whole disk and then make PV from whole VDO disk and put LVM on top of that.
When you already have data, you cannot convert your disk to VDO. You need create new VDO disk, format it, mount it and
copy the data.
In my case, due limited space for migration I created a small LVM volume "vdosrv":
# lvcreate -L 80G -n vdosrv vol0
I converted it to VDO which claims to have 2TB of vitual total size
# vdo create --name=srv18 --device=/dev/vol0/vdosrv --vdoLogicalSize=2T
# mkfs.ext4 /dev/mapper/srv18
See how many space is *actually* free.
# vdostats
# mkdir /mnt/srv18
# mount -o discard /dev/mapper/srv18 /mnt/srv18
Now I moved some data from old volume to /mnt/srv18. I shrank the FS of old volume, I shrank the old LV. And then I
enlarged the new LV.
# lvresize -L +400G /dev/vol0/vdosrv
and let know vdo that it can use the new space:
# vdo growPhysical -n srv18
I repeated this several times.
I have to say that my experience is so far good.
I hope that my notes help someone.
Miroslav