@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+hagen
+lbt
+orignal
+postman
+segfault
+wodencafe
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest30976
Irc2PGuest52859
Irc2PGuest59134
Irc2PGuest99152
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
SoniEx2
T3s|4__
acetone_
aeiou
anon2
b3t4f4c3
bak83
boonst
cumlord
dickless
eyedeekay_bnc
mareki2p
not_bob_afk
poriori
profetikla
qend-irc2p
r3med1tz
radakayot_
rapidash
schwarzchild-radius
shiver_
solidx66
thetia
u5657
uop23ip
w8rabbit
weko_
x74a6
yoppie
eyedeekay
Clearnet primarily, mostly via Tor exits and known VPN endpoints
lbt
eyedeekay: gitlab seems 502 again :(
eyedeekay
Yup just getting on to fix it again
eyedeekay
Backup should not have run though that is confusing...
eyedeekay
Oh, root was running the same backup script as the user, so disabling one did nothing to disable the other
eyedeekay
backup path was hardcoded so I don't get any free disk space back out of it but at least I know why it was still running the backup
eyedeekay
Should be back in about 5 minutes
dr|z3d
have you checked the size of your journal lately, eyedeekay?
dr|z3d
try: journalctl --disk-usage
eyedeekay
good question, no I haven't
eyedeekay
Kinda big, 3.5g, but not that much
eyedeekay
Once gitlab gets booted I've got a bunch of cached docker image layers I'll be able to ditch though
dr|z3d
journalctl --vacuum-time=1d will limit the size to the last day's worth.
dr|z3d
it's also worth running du -h in /var/log/
dr|z3d
also check /var/cache/apt/archives/ to make sure you don't have a cache of all your package updates.
eyedeekay
I do `du -h -d 1 /var/log` that every time because every once in a while I get a log explosion on my laptop and it screws up my day, hasn't happened on this server yet but the server runs stable and my laptop runs sid
eyedeekay
but I have apt-get autoclean running with my unattended-upgrades so I never have any archived apt packages
dr|z3d
ok, good.
eyedeekay
I just never clear the docker build cache while gitlab is down, don't want to delete the wrong thing by accident and having a running container protects it from deletion
dr|z3d
yeah, those docker caches can get huge in a very short period.
eyedeekay
Yeah looks like I've got a lot in it this time
dr|z3d
on a local box/laptop, you might consider mounting /var/log via tmpfs if it's causing ongoing issues.
eyedeekay
Good thought, I'll look into that
dr|z3d
here's a selection of folders you can mount with tmpfs, tweak to taste:
dr|z3d
tmpfs /dev/shm tmpfs defaults,mode=1777 0 0
dr|z3d
tmpfs /run tmpfs defaults,mode=1777 0 0
dr|z3d
tmpfs /tmp tmpfs defaults,mode=1777 0 0
dr|z3d
tmpfs /var/cache/apt/archives tmpfs defaults,mode=1777 0 0
dr|z3d
tmpfs /var/spool tmpfs defaults,mode=1777 0 0
dr|z3d
tmpfs /var/log tmpfs defaults,mode=1777 0 0
dr|z3d
tmpfs /var/tmp tmpfs defaults,mode=1777 0 0
dr|z3d
you'd want to edit fstab, then rm -rf the contents of the folders you've chosen to mount, and then mount -a
dr|z3d
and then, ideally, reboot.
eyedeekay
thanks
dr|z3d
helps with wear and twear on solid state devices.
dr|z3d
aside from being faster generally.
eyedeekay
Seems like a good idea and I don't see anything stopping me, probably will do this today
eyedeekay
Thanks again
dr|z3d
you're welcome
dr|z3d
re /var/log/, anything that may require a persistent log file (e.g. fail2ban), configure to store the file elsewhere for persistence.
zzz
apologies to eyedeekay and Digital Ocean, as he informed me, they are a good company, and we are not on some low-rent $10 plan as I had naievely assumed ))
eyedeekay
They're OK. I would appreciate a more flexible plan layout from them though, eventually(soon) I'll have to look for a provider who can offer that
orignal
zzz, can we assume that all floodfills are ECIES now?
segfault
orignal: do you want to break compatability?
orignal
are you zzz? I guess you are not
zzz
orignal, I see ~2-3% of ffs are ElG
orignal
which versions?
orignal
since we exlude below 0.9.49
orignal
soory 0.9.59
orignal
I want to cleanup lookup code from ElGamal
zzz
min seen 0.9.29, max seen 0.9.48
orignal
but you are not supposed to threat them as floodfills, aren't you?
orignal
as we agreed about 0.9.58 min
orignal
*0.9.59
zzz
I'm just doing a local netdb search; you can do the same
orignal
I just exlude routers < 0.9.59 from floodfills so I guess I can assume ECIES
zzz
i suggest you double-check my numbers by looking in your netdb
orignal
will do
orignal
but I remmeber we rekeyed all routers autmatically
zzz
yes, we rekeyed with some % chance, then gradually increased the % over several releases, then I think I forgot about it for a while, then finally made it 100% ))
orignal
when?
zzz
let me look
zzz
two years ago, 0.9.58
orignal
then 0.9.59 is always 100%
orignal
we are safe to remove ElGamal from lookups
zzz
that sounds right, but the % chance was at every restart so that's why there isn't really anybody between 0.9.48 and 0.9.58
orignal
they are not floodfills for me anyway
zzz
just don't try to send 25519 to a ElG router ))
orignal
ofc I will add this check and error log