| sfox | hello i'm having trouble with devuan 4 | 01:32 |
|---|---|---|
| sfox | claws-mail on my desktop keeps having trouble connecting to the sumbissions port on my mailserver | 01:32 |
| sfox | meanwhile my laptop also running devuan 4 and my roomate don't have any problems sending mail through the server | 01:33 |
| sfox | the network log says SSL/TLS handshake failure | 01:33 |
| sfox | if i keep trying it will eventually go through | 01:33 |
| sfox | but not in a predictable amount of retries | 01:33 |
| rrq | sounds like dns issues | 01:33 |
| sfox | I don't think so, it is actually connecting to the server | 01:35 |
| sfox | here's the server side log: | 01:35 |
| sfox | Apr 16 08:32:31 mail3 smtpd[61032]: bba3e9706424a267 smtp connected address=[2001:470:e918:0:ba97:5aff:fecb:aa50] host=<unknown> | 01:35 |
| sfox | Apr 16 08:32:31 mail3 smtpd[61032]: bba3e9706424a267 smtp disconnected reason="io-error: No TLS error" | 01:35 |
| sfox | i think it's a problem with the tls library | 01:35 |
| sfox | i tried rolling back to libgnutls30 patch level u2 | 01:35 |
| sfox | from u3 | 01:35 |
| sfox | still having this issue | 01:36 |
| sfox | in wireshark claws-mail just seems to stop responding to tcp packets from the server. it's really weird. claws-mail also uses a ssl client hello version 1.0 instead of a 1.2 or 1.3 | 01:36 |
| sfox | which the server does claim to support | 01:38 |
| sfox | but it definitely not ideal | 01:38 |
| sfox | what's also weird is that the imaps port doesn't have this problem at all | 01:45 |
| gnarface | sfox: are you controlling the dns server too? make sure you're passing both tcp and udp to port 53 | 03:55 |
| gnarface | if that doesn't work, try using the same mail client as your roommate | 03:56 |
| sfox | gnarface, they are | 04:14 |
| sfox | and i am using the same client | 04:14 |
| sfox | claws-mail on devuan 4 | 04:14 |
| sfox | bullseye | 04:15 |
| gnarface | damn, weird | 04:17 |
| gnarface | you check versions on all the tls libraries and such? | 04:17 |
| gnarface | there's not much else it could be besides maybe clock drift | 04:17 |
| gnarface | or hardware/connection failure | 04:18 |
| gnarface | is your roommate using the same exact uplink, with the same exact outgoing IP? | 04:18 |
| gnarface | if you're using separate outbound connections i'd consider one of them might be suspect | 04:19 |
| gnarface | but make sure you check your clocks too | 04:23 |
| gnarface | relatively recent changes in default ssl and dns implementations mean stuff tends to break if you're more than a couple minutes off now | 04:23 |
| gnarface | if your clock had started to drift just barely out of range that could explain the intermittent behavior | 04:23 |
| sfox | were both on the same lan segment | 04:56 |
| sfox | checking times | 04:59 |
| gnarface | if you don't want to be running ntp, you can get a quick one-time time sync with the ntpdate program | 05:00 |
| gnarface | with multiple machines on the same LAN though, running ntp against a local time server can be beneficial | 05:01 |
| sfox | i see on my server ntp started on boot but for some reason is not running | 05:01 |
| gnarface | that's odd | 05:01 |
| sfox | yeah | 05:02 |
| sfox | also when i start it and run service ntpd status it says it's running, but wait a few minutes and not anymore | 05:02 |
| gnarface | are you using the same dns servers as your roommate? | 05:03 |
| Xenguy | sfox: for ntp there's also chrony, FWIW | 05:05 |
| sfox | the server is freebsd | 05:05 |
| sfox | gnarface, yes | 05:05 |
| gnarface | note that BSD's "ntp" is not actually ntp, and i have had some compatibility problems with it and real ntp before | 05:07 |
| sfox | comaptibility problems? | 05:10 |
| gnarface | yes, failure to sync time | 05:12 |
| gnarface | sometimes random client exits related to that | 05:12 |
| rwp | Which of the BSDs? | 05:12 |
| gnarface | well, for sure i only know of this problem with openbsd but i assume (perhaps naively) that freebsd is using the same ntp daemon | 05:12 |
| rwp | I haven't had any trouble with them myself on either FreeBSD or NetBSD. | 05:13 |
| gnarface | it does usually work | 05:13 |
| gnarface | but usually is the important qualifier | 05:13 |
| rwp | Sounds like a system that is too far out of sync, such as booting at time zero 1970, and ntpd needing -g option but not given it. | 05:14 |
| rwp | If the time is more than 1000 seconds off by default ntpd gives up unless -g is given in which case it steps the time (like ntpdate). | 05:15 |
| rwp | Most systems should boot with ntpd -g so as to set the time at boot time regardless of if the clock is close or far off. | 05:15 |
| gnarface | the last time i had any problem with it was a long time ago so it could have been fixed by now | 05:19 |
| rwp | For Devuan I think the default is NTPD_OPTS='-g' in /etc/default/ntp file so this happens automatically in Debian/Devuan. | 05:21 |
| sfox | problem was ntpd_sync_on_start was not set and the time different was too large to it killed itself | 05:22 |
| rwp | But for FreeBSD (since you mentioned BSD) there is no default. Must read "man rc.conf" search down /ntp and see ntpd_sync_on_start="YES" should be set to get that same behavior. | 05:22 |
| rwp | Raspberry Pi's always have this problem because they do not have a battery backed clock and so always boot to time zero 1970. | 05:23 |
| sfox | hopefully this fixes it | 05:23 |
| rwp | Raspbian has a clever package hack that sets the time to the timestamp of a file that it saves to hold the last time seen. So it will be recent but not completely correct. Yesterday if it was last run yesterday. Or last week if last run last week. | 05:24 |
| sfox | i can't believe this whole time my servers didn't have the correct time | 05:24 |
| rwp | And if the time is not in sync then as we all know all https certificate validations fail due to time being incorrect. | 05:24 |
| gnarface | pretty much all ARM SoCs in the wild have this problem | 05:24 |
| gnarface | and the quality of clock chips going into all computers these days is significantly worse than it used to be in the 90's; much more drift | 05:25 |
| rwp | The Banana Pi boards that I like have battery pads that one can solder on a backup battery and if so then they have a real time clock. But one would need to do the solder job to add the battery. | 05:25 |
| rwp | sfox, After getting ntp started check the health of it with "ntpq -p". That will return the servers associated and various information. | 05:29 |
| sfox | thanks i was looking for that | 05:29 |
| rwp | The offset and jitter we would like to be small numbers but reality is that those are outside of our control. | 05:29 |
| rwp | The "reach" field is an octal bit map. Each 1 is a hit. It's okay to have some holes. But generally when all working it will be octal 377 all ones. | 05:30 |
| rwp | Imagine a shift register for it where every good ping is a 1 and every missing is a 0 shifted into the pipeline of the shift register. | 05:30 |
| sfox | it's all 37 with the exception of 1 77 | 05:31 |
| rwp | The poll starts out at 64 seconds but as things stabilize it will expand that to 1024 seconds if things are locked in and the network is stable. | 05:31 |
| sfox | what an esoteric piece of software | 05:31 |
| rwp | Since you just starte dit that's all of the ones that came in. 3 is 11 and 7 is 111 so 37 is 11111 and 77 is 111111 | 05:31 |
| rwp | Esoteric? Hahaha! There is really much worse out there. This is telling you the debug information. Which assumes some understanding of what it is trying to say. Which is why I was hoping to hint the parts of it. | 05:32 |
| rwp | But 37 and 77 and eventually 377 is all ones and that's a good response. Means your network is reliable and is not dropping packets. | 05:33 |
| rwp | Since ntp uses UDP the Unreliable Datagram Protocol and routers that are overwhelmed and overloaded drop UDP packets first when needing to shed load. | 05:33 |
| sfox | most of them are 377 now | 05:34 |
| rwp | Which is fine from an ntp point of view. It will handle it just fine. But if the routers are dropping packets then it is an indication that things are overloaded. | 05:34 |
| rwp | Good! 377 is all 1's and meaning that you have in the last 8 attempts been successful talking to the server and peer timeservers. Good. | 05:35 |
| sfox | i guess i should unblock libgnutls30 upgrades and see if it's still an issue | 05:35 |
| rwp | The poll time starts out at 64 seconds. After things become predictable it will back those off to 1024 seconds polling eventually. Assuming the link is stable. | 05:35 |
| sfox | rwp do you know a lot about freebsd? | 05:35 |
| rwp | In the case of an unstable link it will dynamically adapt. | 05:35 |
| rwp | FreeBSD? A lot? I don't know. I use it. But ntp? Have been using it for a lot of years. | 05:36 |
| rwp | (For the lurkers sfox and I were also chatting in #freebsd about ntp too.) | 05:36 |
| brocashelm | i use openntpd instead of ntpsec/ntp nowadays | 06:42 |
| brocashelm | pretty light | 06:42 |
| avbox | Is there a way to install php8.x to oldstable? | 21:00 |
| fsmithred | probably have to backport it if it's not already in beowulf-backports | 21:03 |
| avbox | beowulf-backports is in sources /etc/apt/sources.list. apt-cache search php8 does not give results. So it is not yet on in backports? Or do I have do anything else to lookup for it? | 21:08 |
| brocashelm | i don't think there will be any further backporting to beowulf. chimaera is about to go oldstable | 21:28 |
| brocashelm | especially with the freeze right now | 21:30 |
| avbox | I'm install now chimaera, there is php7.4, is there php8 in backports? | 21:54 |
| brocashelm | unfortunately, no, it looks like php8.2 packages are daedalus and newer | 22:20 |
| brocashelm | https://packages.debian.org/bookworm/php | 22:21 |
| brocashelm | you could maybe try to build php8 from source with chimaera, if you have the correct -dev packages | 22:21 |
| brocashelm | enable the src repo and then run apt build-dep php | 22:22 |
| brocashelm | https://www.spix.nu/linux/how-to-compile-and-install-the-latest-version-of-php-7-from-source-code-on-debian/ | 22:23 |
| Jjp137 | there's also this third-party repo but usual things about third-party repos apply: https://dev1galaxy.org/viewtopic.php?pid=41211#p41211 | 22:24 |
| brocashelm | and then with third-party repos, you can only get support from the actual maintainers of those repos, not devuan/debian | 22:26 |
| golinux | broca | 23:25 |
| golinux | oops | 23:25 |
| golinux | Jjp137: deb.sury.org has been providing php for Devuan for many years and I can't remember ever hearing a complaint. | 23:26 |
| avbox | @golinux: I believe in that I did try to use deb.sury.org, but it complainted about that no beowulf package is available. | 23:46 |
| brocashelm | avbox: please copy and paste output to a paste site like dpaste.org | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!