| micdud | wondering if anyone uses nic bonding on chimaera/ceres ? | 01:00 |
|---|---|---|
| wikan | hmm, why there is no wicd in repo anymore? | 02:11 |
| micdud | deprecieated i think | 02:11 |
| wikan | hmmm | 02:13 |
| JackFrost | https://bugs.debian.org/968033 | 02:13 |
| wikan | ok, thanks | 02:15 |
| wikan | nmcli is much more powerful as i see | 02:15 |
| wikan | but i have to learn it | 02:15 |
| rwp | wikan, wicd depends upon Python 2 and so far no Python 3 version of it. :-( | 02:16 |
| JackFrost | See also: Connman, cmst | 02:17 |
| rwp | wikan, Most people have decided on connman as the most natural replacement for wicd. | 02:17 |
| wikan | hmmm, thanks | 02:17 |
| wikan | saved ;) | 02:17 |
| wikan | well, maybe i do not need any replacement | 02:18 |
| wikan | is it possible to setup wifi to not connect automaticaly? just with ifup? | 02:18 |
| wikan | i did it as "auto" in /etc/network/interfaces | 02:18 |
| rrq | yes. use wpagui | 02:19 |
| wikan | i don't have gui | 02:19 |
| rwp | You can do it all on the command line if you have a simple situation and it doesn't change hugely. | 02:19 |
| rrq | ok. thereäs wpa?cli .. but I havenät used | 02:20 |
| rrq | ok. there's wpa?cli .. but I haven't used | 02:20 |
| wikan | yea, right | 02:20 |
| wikan | so i need a script ;) | 02:20 |
| rrq | wpa_cli (sorry about my swedish keyboard) | 02:20 |
| wikan | i did try it on one machine but it didn't work | 02:21 |
| rrq | if you have a fix setup you can add it into the iface stanza | 02:21 |
| rwp | https://wiki.debian.org/WiFi/HowToUse scroll down to the wpa_supplicant section. | 02:21 |
| fsmithred | there's setnet.sh | 02:21 |
| fsmithred | setnet is in devuan experimental | 02:22 |
| rwp | I think wpa_supplicant is pretty simple. Basically two steps. 1) wpa_passphrase "WPA_SSID" passphrase >>/etc/wpa_supplicant/wpa_supplicant.conf | 02:22 |
| rwp | And 2) auto wlan0\n iface wlan0\n inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf | 02:23 |
| rwp | That's my usual Raspbery Pi configuration. | 02:23 |
| rwp | Oops. I put the \n in the wrong place. Try this 2) auto wlan0\n iface wlan0 inet dhcp\n wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf | 02:24 |
| rwp | But mostly just trying to focus attention on that section of the wiki page. Since that is a long page with lots of case options discussed. | 02:24 |
| wikan | thanks | 02:24 |
| wikan | bookmarked | 02:28 |
| micdud | does devuan change anything to networking scripts to make them work without systemd , or is systemd in debian just a wrapper on top of those scripts ? | 02:29 |
| wikan | i have no idea | 02:38 |
| fsmithred | I don't think so, but there is a package named orphan-sysvinit-scripts that contains the init scripts that some package maintainers have removed. | 02:38 |
| fsmithred | but that package is in the debian repo | 02:39 |
| wikan | ok, time to go to bed | 02:41 |
| wikan | good night | 02:41 |
| * wikan waves | 02:41 | |
| micdud | trying to debug /etc/init.d/networking and ifupdown , both seem to break if there is a bonding interface in /etc/networking/interfaces . boots up ok , with an error or two but functioning, untill you try stop or restart networking . and ifupdown does not work at all on bonding interfaces | 02:44 |
| fsmithred | I don't know about bonding interfaces | 02:44 |
| fsmithred | I know there's an unofficial patch for /etc/init.d/networking to fix a bootup delay | 02:45 |
| rrq | "does not work" is rather general; perhaps you can paste the setup somewhere? | 02:46 |
| micdud | https://pastebin.com/fnHiqGYq | 02:47 |
| rrq | it needs to bring up eth* to link level as well doesn't it | 02:49 |
| micdud | sno | 02:49 |
| micdud | it does it automaticaly | 02:49 |
| rrq | what the doesn't work? | 02:49 |
| micdud | anything after bootup , /etc/init.d/networking stop start restart , nor ifupdown | 02:50 |
| micdud | only thing you can do after bootup is manual echoes to sysfs to deal with bonded interfaces , or restart | 02:50 |
| rrq | are you sure eth* are up automatically? | 02:51 |
| micdud | yes , that the way it deals with it , bonded interface automaticaly brings up slaves | 02:51 |
| micdud | tried it both ways , and manualy bringing enslave interfaces and setting them to bond-master instead of enslaving rough the bond interface seems to break things | 02:52 |
| rrq | ok. and after "ifup bond0" all looks up, with IP assignment, but it doesn't work? | 02:54 |
| micdud | no it works after bootup , everything is ok and has been since beowulf | 02:55 |
| micdud | but trying to stop netowrking and reconfigure the bonded interface does not | 02:55 |
| micdud | need to reboot everytime or manualy go trough echoes to sysfs to reconfigure everything and then manualy bring up the bonded interface | 02:56 |
| rrq | well, you wouldn't stop networking, but rather just "ifdown bond0" before reconfiguring | 02:56 |
| micdud | ifdownup errors on anything to do with bonded interrface | 02:57 |
| micdud | cannot up or down it | 02:57 |
| rrq | what does "ifdown bind0" say? | 02:57 |
| rrq | bond0 | 02:57 |
| micdud | hold on , let me fire up that machine | 02:58 |
| micdud | ifdown: interface bond0 not configured | 03:01 |
| rrq | hmm and "ifup bond0" ? | 03:02 |
| micdud | hold | 03:04 |
| micdud | https://pastebin.com/n2geH6tZ | 03:08 |
| micdud | that mainly errors out as it is trying to echo in to sysfs , but interface was never brought down so , naturally | 03:10 |
| rrq | to me it suggests it expects eth* to be up at link level when bonding; but you may have tried that | 03:12 |
| rrq | eg "pre-up ip link set eth0 up" | 03:14 |
| rrq | or separate iface stanzas as manual without configurations | 03:14 |
| rrq | like "iface eth0 inet manual" ... then "auto eth0 eth1 bond0" to configure them in order | 03:16 |
| micdud | i see , have not tied that , had them as auto and manual , but also bond-master bond0 , intstead of bon0 enslaving them | 03:17 |
| rwp | I think, now that we have NM and such that grabs undeclared interfaces, that one must now declare interfaces manually or other tools will think they are fair game to use. | 03:17 |
| rwp | So for example on my system with a bridged interface I have to declare "iface eth0 inet manual" to avoid other tools from trying to use it. | 03:17 |
| rwp | It's been at least 7 or 8 years since I last messed with bonded interfaces but I remember using ifupdown with them at that time. | 03:19 |
| rwp | I think the intention is that ifupdown will work with them. | 03:19 |
| micdud | i had a server with beowulf and bonding , but never had to mess with it after bootup | 03:20 |
| micdud | same thing "ifdown: interface bond0 not configured" and nothing with -v | 03:22 |
| rrq | right; so you added the pre-up lines and rebooted? | 03:25 |
| micdud | yup | 03:27 |
| rrq | hmm quick browse suggests bonding mode 4 "is complicated" | 03:31 |
| daemon | hey all not 100% sure if this is the right channel to ask, but with KVM would it be possible to do this. Assuming a system with 64G of ram, I would like to setup 3 VM's each with a Max memory size of 32G (balooning), but on top of this I would also like to protect 8G of the system memory for use by the host only. I would ideally like a way to set a priority for each VM and memory requests, so that more important production boxes do not end up | 03:33 |
| daemon | fighting with those that are less so, with devuan as the host of course. | 03:33 |
| rrq | micdud: maybe mode 6 works better? | 03:33 |
| micdud | it might be on switch side, but here i am just dealing with debian side of it , can switch to 6 and still have same results withouth needing to configure the switch | 03:33 |
| rrq | ... yeah, my random web search result suggests so :) | 03:34 |
| micdud | <daemon> looking trough my bookmarks , i remember hosts need balooning drivers install for it to work , and i remeber pinning cpus just for guest and leaving a few for host | 03:37 |
| adhoc | daemon: when you hit swap becuase of memory exhaustion, performance will suck. a lot. | 03:38 |
| adhoc | daemon: the first rule of VMs is; Never over subscribe RAM. | 03:38 |
| daemon | micdud, that should be good for the balooning and cpu pinning, any idea about reserving 8G for the host that absolutely cannot be used by the VM's and allocating memory space based on priority (dependant on which vm it is) | 03:39 |
| adhoc | rrq: I wrote something up on bonding ethernet and plumbing VLANs over it; http://vk5fj.blogspot.com/2012/04/vm-on-kvm-on-vlan-on-bridge-interface.html | 03:41 |
| daemon | adhoc, it should never hit swap, the clients balooning driver simply takes up memory that is not availible to be assigned | 03:41 |
| adhoc | yes that was for debian almost a decade ago, but it works on devuan, i tested it about a month ago. | 03:41 |
| adhoc | daemon: good luck with that =) | 03:42 |
| adhoc | did not know that ballooning was a thing on KVM, will have to look into that =) | 03:45 |
| adhoc | daemon: i've used swap into tmpfs on other machines, which was gnarley, but works... | 03:45 |
| micdud | <adhoc> vlan part is not what i am dealing with , and bonding works after bootup if you do not touch it , but /etc/init.d/networking stop,start,restart or ifupdown are broken with bonding | 03:45 |
| adhoc | micdud: interesting | 03:46 |
| adhoc | micdud: so you are tying the IP to the bond0 ? | 03:46 |
| adhoc | the other thing is that once a bond interface is up, with slave ethernet interfaces, you can't change it, you need to reboot and configure at bootstrap time | 03:47 |
| adhoc | this seems to be a thing on all debian based distros I have tried | 03:47 |
| adhoc | no idea if that is an issue on RHEL based distros. | 03:47 |
| adhoc | micdud: admittedly, the instances where I use this, machines are setup and tend to run for months at a time, between patching cycles | 03:49 |
| micdud | <daemon> with hugepages settups i remeber hosts would only have access to that portion of the memory and host would not | 03:49 |
| micdud | i ment guest would have access and host would not | 03:50 |
| micdud | but do not remeber if guest could share that part | 03:51 |
| micdud | <adhoc> interisting , reading docs seems like ifupdown should deal with bonding , and a few bugs sugjest it was broke, but fixes since | 03:56 |
| micdud | i know you can manualy down it and reconfigure trough sysfs and bring it back up manualy again , just wish ifupdown was a script i can read and not a binary | 03:57 |
| rrq | micdud: you've probably been there, but "man 5 interfaces" tells most of the story | 04:16 |
| adhoc | micdud: ifdown the interface athte IP level, sure, but the underlying bond is set. | 04:22 |
| micdud | <adhoc> doesnt even do that just says "ifdown: interface bond0 not configured" | 04:23 |
| micdud | ip still assigned | 04:23 |
| micdud | ill figure it out eventualy , and upstream will probably say its another feature :) | 04:24 |
| rrq | apparently bond0 has failed during configuration (ifup) .. you maye want "ifdown --force bond0" to enforce deconfiguration actions anyhow | 04:24 |
| adhoc | rrq: interesting, i have never got that to work. hopefully that has been fixed =) | 04:26 |
| micdud | --force seems to work , even de configures the bonding | 04:27 |
| adhoc | oh nice, glad to see there is progress =) | 04:28 |
| rrq | I'd also guess that a "down ip link del bond0" setting could do wonders to it .. actually deleting that interface when deconfgured | 04:28 |
| micdud | thats what i figured i would need, some manual pre-down post-down | 04:29 |
| micdud | thanx guys, on the right track here now | 04:30 |
| micdud | this is all for testing a new router, to up the routable/firewallable/vlans bandwith over a canned devices that cannot cope even with linux firmware , is cpu/nic bound , so a small box with bonded nics should work | 04:35 |
| adhoc | micdud: your next limitation will be processes to deal with socket handling | 04:37 |
| adhoc | micdud: if you have ip:socket round robin on the bond, then a single stream will still tie up a single NIC | 04:37 |
| adhoc | micdud: else you can round robin from the linux box with a different mode | 04:37 |
| adhoc | but using the IP:socket streams to balance is good too, even if on stream smashes on NIC, other streams can use the other NIC in a lower latency way than some of the other modes | 04:38 |
| micdud | i know that sending londbalancing is set on server for lacp , but receive is on switch side , playing with different modes on each to see which is best for this settup | 04:40 |
| micdud | trying with catalyst switches and dell powerconnects | 04:41 |
| cytokine_storm | rfkill blocked my wifi suddenly automatically, without any intervention. how? | 05:01 |
| adhoc | cytokine_storm: how do you know? | 05:10 |
| micdud | seems that setting interface to manual instead of static for bond0 fixes all the problems , now i can ifup and ifdown bond0 | 05:22 |
| adhoc | micdud: you want manual if you then run a bridge on top of the interface | 05:24 |
| adhoc | micdud: actually might be an order of operation issue | 05:24 |
| adhoc | if you set it to manual and then post-up; ip addr ... | 05:24 |
| micdud | i was not there yet , just trying to get the bond to work right , so i do not have to reboot all the time to reconfigure it :) | 05:24 |
| adhoc | oh good =) | 05:25 |
| micdud | is a bridge necessary for vlans ? i remeber i can just bring them up as subinterfaces eth0.10 etc ? | 05:31 |
| adhoc | you can bring up bond0:0 | 05:32 |
| adhoc | you can run a bridge on the bond0 too | 05:32 |
| adhoc | but eth0.10 is the notation for vlans, eth0:10 for different IPs | 05:33 |
| adhoc | if i remember rightly | 05:33 |
| adhoc | er, I think that is the right way around | 05:33 |
| cytokine_storm | adhoc: wifi was working and then the network went off suddenly. then i checked rfkill and it showed blocked | 05:34 |
| adhoc | i have an IP on the bond0 on one of the servers at work, but that is ubuntu and thus configired differently | 05:35 |
| adhoc | cytokine_storm: can you find an event/action in your logs that shows why ? | 05:35 |
| micdud | that what i usually had , for just servers and bonding | 05:35 |
| micdud | no vlans | 05:35 |
| adhoc | understoof. | 05:35 |
| adhoc | s/f/d/ | 05:36 |
| cytokine_storm | looking | 05:37 |
| qwestion | Hi any devices can be ought preinstalled w devuan? | 05:50 |
| micdud | not that hard | 05:51 |
| micdud | to install | 05:51 |
| gnarface | so far as i know the answer is "no" | 05:52 |
| gnarface | i could be wrong | 05:52 |
| gnarface | it is really usually pretty easy to install. you should try the live image if you are nervous | 05:53 |
| qwestion | micdud: imagine wanting your whole family or neighborhood to switch | 06:13 |
| micdud | id setup a cloning operation , and keep it down-lo so the man does not find out | 06:14 |
| qwestion | gnarface: would arm image work on arm servers or something like pine64 rock64 pinephone synquacer odroid c2/c4/n2? | 06:15 |
| golinux | qwestion: There are install guides with screenshots here: https://www.devuan.org/os/install | 06:19 |
| golinux | Also plenty of youtube videos | 06:19 |
| qwestion | golinux: servers? | 06:20 |
| adhoc | qwestion: i have an arm server on a rock pro 64 | 06:21 |
| qwestion | Can it fail if stock Debian works on a device? U use same kernel, also same firmware files? | 06:21 |
| adhoc | need to squeeze some rotating disks in it yet | 06:21 |
| adhoc | qwestion: depends on the device and its hardware requirements for the firmware. | 06:22 |
| qwestion | adhoc: I meant synquace, amd, thunderx etc | 06:22 |
| adhoc | i recognise amd out of that lot | 06:22 |
| qwestion | adhoc: I meant synquacer, amd, thunderx etc | 06:22 |
| adhoc | what are you trying to do ? | 06:22 |
| adhoc | for those ARM based systems that use an eMMC, you can get a USB adaptor, that you 'dd' an image to. | 06:25 |
| adhoc | then you can mount the image and adjust settings, like hostname and IP | 06:25 |
| gnarface | qwestion: embarrassingly enough, i don't think there's actually pine64 images up there yet, but i didn't have any problems building one here | 06:25 |
| adhoc | then plug the eMMC into the ARM system and boot it. away you go | 06:25 |
| adhoc | gnarface: i pulled the rock pro 64 image and ran with it. | 06:26 |
| adhoc | might be devuan3, not 4 though. | 06:26 |
| golinux | qwestion: CD1 is for server installation. This from https://www.devuan.org/get-devuan | 06:26 |
| golinux | server (~670 MB): CD1 of a 4 CD set that allows for a complete off-line server/minimal installation. | 06:27 |
| gnarface | aren't those instructions i386 and amd64 only? | 06:27 |
| golinux | I saw a server youtube video a while ago. | 06:27 |
| golinux | Yes. | 06:27 |
| gnarface | they're asking specifically about ARM | 06:28 |
| qwestion | https://www.chip1stop.com/USA/en/view/dispDetail/DispDetail?partId=SOCI-0000001&cid=SOCIEB | 06:28 |
| qwestion | https://www.96boards.org/documentation/enterprise/developerbox/downloads/debian.md.html | 06:28 |
| gnarface | oh, hmm, there might be links to arm instructions here... | 06:28 |
| qwestion | Custom kernel Debian 9 is default | 06:29 |
| adhoc | https://arm-files.devuan.org/ | 06:30 |
| golinux | ARM discussions here https://dev1galaxy.org/viewforum.php?id=24 | 06:30 |
| qwestion | Can I use this custom kernel in a devuan.3? Arm image | 06:30 |
| adhoc | qwestion: depends on hardware, what is the device you want to use ? | 06:30 |
| qwestion | adhoc: see 2 links above | 06:31 |
| * adhoc reads | 06:31 | |
| qwestion | Likewise can I just use mobian kernel if devuan images fail? | 06:32 |
| adhoc | honestly, that question is probably best answered in #devuan-arm | 06:33 |
| adhoc | it depens on which aarm64 cpu and chipset is on that board | 06:34 |
| adhoc | ATX based arm64 MoBos is a good step forward =) | 06:35 |
| adhoc | qwestion: you have browsed; http://www.socionext.com/en/download/catalog/MN04-00002-5E.pdf | 06:37 |
| adhoc | hmm; CPU SynQuacer SC2A11 (Arm Cortex-A53, 24-core) | 06:38 |
| gnarface | qwestion, qwestion2: you can probably boot a devuan chimaera rootfs with the kernel and u-boot from any other relatively recent distro image that is known to work for those particular boards, i just don't know off the top of my heads which ones | 06:56 |
| gnarface | like i said, i just built my own, it worked fine with the upstream u-boot and the debian source package from unstable | 06:57 |
| gnarface | debian kernel source package* | 06:57 |
| gnarface | 5.15.2 or 5.15.5 i think | 06:57 |
| gnarface | it shouldn't be too picky though about which version | 06:57 |
| qwestion | gnarface: source means I need to compile? | 06:58 |
| gnarface | yea, the thing is that a bunch of the ARM builds are vendor and cpu-model specific, so it's not just as simple as one image that supports all ARM boards, or even all ARM64 boards | 06:59 |
| gnarface | the chimaera README on arm-files mentions several allwinner CPUs earlier than the pine64 one, but not the A64 that is actually in the pine64 boards, which is why i built my own | 06:59 |
| gnarface | if there's a rock64 image on there for an earlier devuan release though, that very likely might work fine for chimaera for headless servers anyway | 07:00 |
| gnarface | i'm running an older kernel on several other headless machines but in most those cases also custom builds so i don't know for sure on that either but chances are very good | 07:01 |
| gnarface | the latest ubuntu image is also a likely candidate as a base image you can swap the rootfs out with too | 07:01 |
| gnarface | i'm steping away again momentarily but i can help you build your own later if you still haven't figured it out | 07:02 |
| qwestion | gnarface: ty | 07:11 |
| micdud | <rrq>,<adhoc> thanx for help today | 08:29 |
| systemdlete | I'm experiencing occasional loss of email messages. I have a program (bareos backup) which sends a message for various purposes. Normally, it sends a message indicating successful completion of backups for each one of the backups I run. But every once in a while a message does not make it to my inbox. I have examined mail.log for one | 08:37 |
| systemdlete | such instance that occurred today, and I can map the message identifiers from the log to the messages that did make it to my inbox, except for the one in question. When I say "message identifier," I am talking about something like "20220116222708.812C5544@myhost.mynet," e.g. I google searched for this question, but (once again ;( ) my | 08:37 |
| systemdlete | search fu seems to be lacking. | 08:37 |
| systemdlete | This is not earth-shattering, but it is noticeable, because I use the total count of messages with subject line indicating success as a means of double-checking that all my backups ran. (I have a better way now, but it still is useful to receive these emails.) | 08:38 |
| systemdlete | this is all happening on devuan chimaera with postfix and dovecot-imapd. Since I do see message logs for all the backup jobs in the mail.log, I am assuming that bareos is not the culprit. It seems to be something to do with either postfix or dovecot (or maybe some kind of other system config issue, idk). | 08:40 |
| systemdlete | Oh. And I am viewing emails via Thunderbird on a remote beowulf system via IMAP. All emails from bareos go to the one email account on the machine hosting bareos. | 08:43 |
| systemdlete | I can also see the inbox using tbird on the bareos system itself. Same situation--same missing email. | 08:50 |
| systemdlete | Not sure what that proves but I provide this data point for completeness. | 08:50 |
| rwp | Hi systemdlete. Normally I would identify the postfix message queue id for the message when it enters the system. | 08:50 |
| rwp | Then I would trace that queue id through the logs. At some point it will be logged the disposition of the message. | 08:51 |
| rwp | Since you have the message-id you could grep the logs for it and use it to find the queue id. | 08:51 |
| systemdlete | I have the queue id from the mail.log. What other log would you look at? | 08:51 |
| rwp | Then grep the logs for the queue id. | 08:51 |
| rwp | Everything will be in the mail.log | 08:51 |
| rwp | In particular look for the "status=" part of the disposition. It will normally say "status=sent" in the case of a normal transfer to another system. | 08:52 |
| systemdlete | the message that is missing does show up in the mail.log, and it is disposed of exactly the same as the other messages. | 08:52 |
| rwp | Or it might say status=bounced or other things. | 08:52 |
| rwp | Does it have a "delivered to" status? | 08:53 |
| rwp | In my case my local delivery will be to procmail. So I will see something like this "status=sent (delivered to command: IFS=' ';exec /usr/bin/procmail || exit 75 #rwp)" | 08:54 |
| rwp | In which case then we know the message was successfully handed off to procmail. | 08:54 |
| rwp | If I needed further debug I would enable the procail log file and then look at it and trace through messages there. | 08:55 |
| systemdlete | status=sent (delivered to command: procmail -a "$EXTENSION") is the last part of the last log message corresponding to the queue id | 08:55 |
| rwp | Then it is the same for you. It was successfully handed off to procmail. | 08:56 |
| rwp | Do you have a .procmailrc file that would have rules and configuration for it? | 08:56 |
| systemdlete | no | 08:56 |
| systemdlete | I only use thunderbird | 08:56 |
| rwp | I only use mutt. Which has nothing to do with procmail. | 08:57 |
| systemdlete | rwp, keep in mind that nearly every day, I get mail for all the jobs. It is only occasionally that a message is being dropped for some reason. And it seems random. Sometimes when it happens, only one message goes missing; other days multiple (but usually only one or two) | 08:58 |
| rwp | If you don't have a .procmailrc file then it will simply deliver the mail into the default system mailbox. Probably /var/mail/$USER | 08:58 |
| systemdlete | so you think it might have ended up in /var/mail$USER ? | 08:58 |
| rwp | I understand. Intermittent failures are the hardest and most annoying. | 08:58 |
| rwp | IIRC that is the default location without a .procmailrc file. I always have a .procmailrc file and have for so many years I don't remember the default without it. | 08:59 |
| rwp | But it would do the same thing for every message. And as you have pointed out you are getting most of your messages. | 08:59 |
| systemdlete | doesn't dovecot-imapd (and other imap agents) use that file to retrieve messages for MUA's? | 08:59 |
| rwp | Dovecot wants to see the messages in a Maildir type mailbox. Usually in ~/Maildir/ in your home directory. | 09:00 |
| rwp | Therefore that is where I configure my mail to be delivered. | 09:00 |
| systemdlete | I was kind of hoping there was a dont_drop_messages=1 that I could add to my mail config... :D | 09:00 |
| rwp | However you said you had no configuration. | 09:00 |
| systemdlete | Well, certainly on my remote machine where I actually read my mail, there is no .procmailrc file in the $USER home directory | 09:01 |
| rwp | Is that where your mail is getting delivered to normally? And then served out to IMAP by Dovecot? | 09:01 |
| systemdlete | All the important action happens on the machine running bareos. It just so happens that I connect to the imap server on that same machine from a remote machine where I normally look at the messages. But as I noted above, I do not see the missing message when running tbird on the bareos machine itself either. | 09:02 |
| systemdlete | So bareos, postfix, procmail, dovecot, and friends are all running on one system. | 09:02 |
| systemdlete | I also checked the file system sizes and space availability. | 09:03 |
| systemdlete | on both systems. In particular, the /var file system where mail is kept. | 09:04 |
| systemdlete | hold on, rwp, let me grep for the missing message queue id in the /var/mail/$USER file... | 09:04 |
| rwp | The /var/mail/$USER file is an mbox format file. It will be one file with possibly multiple messages separated by "^From " markers. | 09:05 |
| systemdlete | I grepped that file on both systems. Nada. | 09:06 |
| systemdlete | also, rwp | 09:06 |
| systemdlete | this missing message is sandwiched in between two other successfully run backups | 09:06 |
| systemdlete | and I received emails for each of those. | 09:06 |
| systemdlete | may I post a short 3-liner here? | 09:08 |
| rwp | Whatever is happening will be something you will need to figure it out. | 09:08 |
| systemdlete | (don't wanna get yelled at) | 09:08 |
| systemdlete | rwp: I know, I know... :)) | 09:08 |
| rwp | The global anti-flood bot is the one that will get bad. Do it slow one line at a time. | 09:08 |
| systemdlete | backup-jobA 886CE1FFE 03:06:06 | 09:09 |
| systemdlete | backup-jobB(?) A49D41FFE 03:06:13 | 09:09 |
| systemdlete | backup-jobC 97938255B 03:06:36 | 09:09 |
| rwp | Is that the dovecot log? It's not the postfix nor procmail logs. | 09:10 |
| systemdlete | What I did is make a short file with this info, copy-and-pasting the info from the mail.log. jobA completed and sent mail at 3:06:06, and was followed by another job that finished up about 7 seconds later. But it while it did send mail, it did not make it to procmail or soemthin | 09:11 |
| systemdlete | or something. Then 23 seconds later, the next email I did receive is noted. | 09:11 |
| systemdlete | I am wondering if the rather close timings have something to do with this. | 09:11 |
| systemdlete | I think jobB is the missing one because I can't find it anywhere in my inbox or /var/log/$USER | 09:12 |
| rwp | Not enough information yet to know what is happening or why you are not seeing your missing message in your mailbox. | 09:12 |
| systemdlete | Well, I'm just saying this is the sequence of events. I thought that might be useful for running this down. Certainly, for my own research into this, it has been. I just shared it with you here for edication. | 09:13 |
| systemdlete | edification. | 09:13 |
| systemdlete | clarity. whatever... | 09:14 |
| systemdlete | does procmail keep its own log in /var/log? | 09:14 |
| rwp | All I can do is describe how things work normally. | 09:15 |
| rwp | If a log file is enabled then procmail will log to the specified location. | 09:15 |
| systemdlete | where does procmail spec its location? | 09:16 |
| rwp | But you said you did not have a .procmailrc file. (Alternatively /etc/procmailrc) | 09:16 |
| systemdlete | oh | 09:16 |
| systemdlete | ok | 09:16 |
| systemdlete | so procmail doesn't write its log to /var/log/mail.log ? | 09:16 |
| rwp | No. | 09:16 |
| rwp | Most things in Unix are completely silent when they work correctly. cp, mv, rm, none of those log to /var/log anywhere. | 09:17 |
| rwp | It would help me to verify where your Dovecot thinks the mail is located: grep mail_location /etc/dovecot/local.conf | 09:17 |
| systemdlete | but procmail is not a command line utility either... or is it? | 09:17 |
| rwp | Mine says: mail_location = maildir:~/Maildir:LAYOUT=fs | 09:17 |
| rwp | Sure procmail is a command line utility! | 09:18 |
| rwp | procmail also happens to be the default postfix delivery mechanism | 09:19 |
| systemdlete | /etc/dovecot/conf.d/10-mail.conf:mail_location = mbox:~/mail:INBOX=/var/mail/%u | 09:19 |
| systemdlete | (output of grep) | 09:19 |
| rwp | Interesting. Yours is configured for two mailboxes. The first is ~/mail in your home directory. The second is /var/mail/$USER | 09:19 |
| rwp | Unfortunately I am not great at dovecot configuration. I set it up here, it's working, I don't mess with it. So I am definitely not an expert. | 09:20 |
| rwp | But the above means that you will find your mail either in ~/mail or in /var/mail/$USER on your system. | 09:20 |
| systemdlete | there is nothing of interest in ~/mail though. Just some empty directories reflecting some of the various accounts I have configured in tbird | 09:21 |
| rwp | If it is ~/mail then that is not a default and it would need to have been configured. /var/mail/$USER is the default though. So I suspect all of your mail is there. | 09:21 |
| systemdlete | and none of those have a timestamp date past 12/31/2021 | 09:21 |
| rwp | Then ~/mail is a dead end. We can ignore it. That means all of your mail is being delivered to /var/mail/$USER right? That is the default. So no configuration ends up there. | 09:22 |
| systemdlete | yes, I agree | 09:22 |
| rwp | /var/mail/$USER is an mbox style one file with many messages. It uses a .lock file when adding or deleting messages from there. | 09:22 |
| rwp | So far nothing has indicated a specific problem with delivery there but if there is a .lock failure of some sort then possibly that could account for mail being lost there. | 09:23 |
| rwp | What are the permissions on /var/mail itself? ls -ld /var/mail | 09:23 |
| rwp | Mine are: drwxrwsr-x 2 root mail 4096 Aug 16 15:42 /var/mail | 09:23 |
| rwp | Generally I think the recommendation is to deliver to a Maildir type mailbox and have dovecot serve the mail from there. | 09:24 |
| rwp | Maildir type mailboxes have one file per message. And are constructed such that no file locking is needed for adding or deleting messages. | 09:24 |
| rwp | And unfortunately it is very late here. I need to crash. But perhaps the discussion helped in some small way. Even if we still have no idea yet what is happening. | 09:25 |
| systemdlete | sure, I appreciate it. thanks | 09:25 |
| systemdlete | I'll continue looking | 09:26 |
| systemdlete | drwxrwsr-x 2 root mail 4096 Jan 17 00:24 /var/mail | 09:26 |
| systemdlete | note the date though. mine is today; yours is from months ago | 09:27 |
| rwp | I don't use /var/mail/rwp here. So mine being months ago is normal. | 09:29 |
| rwp | If it were me I would create a ~/.procmailrc file for you with this contents: COMSAT=no\n LOGFILE=$HOME/log/procmail.logfile\n VERBOSE=on | 09:29 |
| rwp | Three lines. I joined them here. But put each assignment on a separate line. | 09:30 |
| rwp | Then send yourself a test message. See if the log file shows up. See if it says that it did in the log file. | 09:30 |
| rwp | By default DEFAULT=/var/log/$LOGNAME which is okay for your default setup. | 09:30 |
| rwp | If that works then you should have some log file tracing of what is happening when mail is passed to procmail and delivered for you. | 09:31 |
| rwp | If things are blown up by that then of course remove the .procmailrc file and restore things to the way they were before. | 09:31 |
| systemdlete | know what? | 09:31 |
| rwp | No. What? | 09:31 |
| systemdlete | I was looking at ~mail on the remote system | 09:31 |
| systemdlete | but | 09:31 |
| systemdlete | when I look at the ~/mail on the bareos system, it is more interesting | 09:32 |
| systemdlete | there are directories and files there that are recent. | 09:32 |
| systemdlete | keep in mind, that the mail_location I gave you is right -- it's from the bareos server | 09:32 |
| rwp | If the directories have new, tmp, cur directories in them then that is a Maildir format mailbox. | 09:32 |
| systemdlete | strange thing though is they appear to be files containing multiple messages, not one per | 09:33 |
| rwp | I suspect that ~/mail will have ~/mail/{new,tmp,cur} directories in them. Maybe. | 09:33 |
| rwp | If that is true then that is the original Berkeley mbox format. Just like /var/mail/$USER is that same format. | 09:33 |
| systemdlete | no new,tmp,cur in mail. There is a INBOX and Trash | 09:34 |
| rwp | I am not following all of what you have said about the backup server versus your other server. Sorry. | 09:34 |
| rwp | I would think that your backup server would transfer the mail to your mail server. With SMTP from postfix to postfix. And then your mail server would deliver it to you. | 09:34 |
| systemdlete | ok, from here on out, I am only talking about the bareos server, where postfix, dovecot, bareos, and procmail are running | 09:34 |
| systemdlete | no | 09:34 |
| rwp | And you say you are receiving some messages. So that seems impossible that some would be one way and some another way. | 09:35 |
| rwp | Okay. If everything is on one system then that does make things simpler to think about. | 09:35 |
| systemdlete | not how I am doing it here. I use imap in tbird on a remote system just to look at the mail. No smtp going on at all in this scenario (though I do use it for other things) | 09:35 |
| systemdlete | right. | 09:35 |
| systemdlete | sorry if that was not clear | 09:35 |
| rwp | Once things get to thunderbird and imap then it doesn't really matter that the client is on a different system. That's mostly expected. | 09:36 |
| systemdlete | agreed | 09:36 |
| rwp | The mail isn't on the thunderbird system. It's on the server system running dovecot. | 09:36 |
| systemdlete | and, as I said previously, the same scenario plays out if I run tbird on the server itself. no difference there | 09:36 |
| systemdlete | (right, agree) | 09:36 |
| rwp | But... It's now 1:36am for me. I am at the end of my brain day. If it were earlier I could keep walking through it with you. But I must sleep. | 09:37 |
| systemdlete | but thunderbird may make copies of the mail messages or its headers locally on the remote system. | 09:37 |
| rwp | Good night and good luck! | 09:37 |
| systemdlete | thanks again rwp | 09:37 |
| systemdlete | good night | 09:37 |
| * systemdlete keeps talking to his rubber ducky... | 09:39 | |
| * wikan waves | 10:25 | |
| chomwitt | goodmorning. I see in g++'s control file no tags. But apt-cache show g++ will show tags. So where did apt-get got this info from? | 10:51 |
| furrymcgee | there is a tags database on debtags.debian.org see alsa /var/lib/debtags or /var/lib/lists | 11:04 |
| furrymcgee | I dont know if devuan has its own tags | 11:04 |
| chomwitt | hi | 11:28 |
| chomwitt | there is no /var/lib/debtags in my chimaera system | 11:28 |
| chomwitt | there is a /var/lib/apt/lists | 11:38 |
| chomwitt | lets see | 11:38 |
| chomwitt | if tags are a debian specific thing then how apt-cache finds tags? | 11:40 |
| furrymcgee | apt update downloads the list for example http://deb.devuan.org/merged/dists/stable/main/binary-all/Packages.gz | 11:43 |
| furrymcgee | please use codesearch for sources of /var/lib/debtags https://codesearch.debian.net/search?q=%2Fvar%2Flib%2Fdebtags | 11:50 |
| chomwitt | a! /var/lib/apt/lists$ emacs deb.devuan.org_merged_dists_chimaera_main_binary-amd64_Packages it has tags! | 11:52 |
| chomwitt | sorry for that | 11:53 |
| chomwitt | anyway thanks furrymcgee . | 11:53 |
| chomwitt | so when devuan creates it's Packages files it pulls info from the debian tags database? | 11:55 |
| furrymcgee | access to the database is required to push tags for pull I would use the public released files | 12:01 |
| adhoc | mirda: you're welcome. hope it all works out =) | 12:04 |
| sabas3dgh | hello devuan users! | 15:04 |
| sabas3dgh | YouCompleteMe unavailable: requires Vim compiled with Python (3.6.0+) support. | 15:04 |
| sabas3dgh | Need help with this ... ^^^ | 15:04 |
| sabas3dgh | fsmithred, Hello; 😄 | 15:05 |
| sabas3dgh | Do I need vim-nox? | 15:08 |
| fsmithred | sabas3dgh, what are you trying to do? | 15:16 |
| fsmithred | did you try installing vim-youcompleteme? | 15:17 |
| fsmithred | it depends on vim-nox OR vim-python3 | 15:18 |
| fsmithred | oh, there's no vim-python3, so yeah, you need vim-nox | 15:20 |
| sabas3dgh | fsmithred, installing YouCompleteMe from github. Do you say we have it packaged? | 15:52 |
| fsmithred | sabas3dgh, yes, it's in chimaera | 15:52 |
| fsmithred | maybe more | 15:52 |
| fsmithred | apt policy vim-youcompleteme | 15:53 |
| sabas3dgh | fsmithred, very much needed info; thank you sa always. | 15:56 |
| sabas3dgh | as always | 15:57 |
| pingpongball | Guys | 16:19 |
| pingpongball | would i know why those packages are banned? | 16:19 |
| pingpongball | https://pkgmaster.devuan.org/bannedpackages.txt | 16:19 |
| gnarface | they either depend on systemd or they actually are systemd | 16:21 |
| bb|hcb | adhoc, qwestion: Did you manage to boot that SynQuacer board with Devuan? | 17:55 |
| qwestion | bb|hcb: no i don't have day vice yet, eval feasibility | 17:56 |
| qwestion | Device | 17:56 |
| bb|hcb | OK, 10x! The device looks promising... | 17:58 |
| bb|hcb | They state that Debian is supported, that means that in the worst case the Debian install can be converted to Devuan | 18:08 |
| rkta | installing mosquitto the install fails because /run/mosquitto is not created, mkdir solves the install problem. When I then use service mosquitto start it fails with EACCESS. How can I find out which user:group /run/mosquitto should have? | 19:15 |
| wikan | sorry if I will enter and leave - i have network issues | 19:20 |
| wikan | i hope so | 19:20 |
| wikan | error sending C_RXON_ASSOC: enqueue_hcmd failed: -5 | 19:24 |
| wikan | is it network problem or chipset? | 19:24 |
| adhoc | bb|hcb: no. I do not have a SynQuacer board. | 23:48 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!