Please wait...
0 files
Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
You posted this while i was reloading a VM to test.. so you beat me to it ;) But ya success again here too. yay.
Thu Nov 28 2024 09:53:00 UTC from alcomys Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
Hi Guys.
I can confirm that the new version works on the fly.
No problems anymore on my Rapsberry pi 3/4 and debian 12 bookworm.
The password problem when login at webcit has also solved.
We are good to go now. Thanks to the creator for this nice update.
Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
Thu Nov 28 2024 15:07:37 UTC from Nurb432 Subject: Re: All recently reported bugs are likely fixed in Citadel 1007You posted this while i was reloading a VM to test.. so you beat me to it ;) But ya success again here too. yay.
Thu Nov 28 2024 09:53:00 UTC from alcomys Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
Hi Guys.
I can confirm that the new version works on the fly.
No problems anymore on my Rapsberry pi 3/4 and debian 12 bookworm.
The password problem when login at webcit has also solved.
We are good to go now. Thanks to the creator for this nice update.
I'm sorry Nurb432,
I can install this with my eyes closed now :) , lol
So I made two SD-cards with different systems and try to install on it so that i can switch fast between systems.
But everybody is happy now i think of a working easy-install.
Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
So let me ask a question to anyone who is paying attention right now.
What made you decide to go with the Easy Install build instead of the Docker build?
One of the guiding principles of the Citadel project is that we want it to be really easy to get the software installed. Easy Install was built with that goal in mind, but the Docker install is even easier. So what was it that made those of you who did the Easy Install decide to go that way? Did you try the Docker build and it didn't work? Was there something missing from it? Or just an aversion to using Docker out of unfamiliarity? Something else?
The target audience for the Citadel system has changed over the years. In the 1980s it was just the BBS crowd. In the late 1990s/2000s it became popular with people who needed a simple groupware server. Today, with the mainstream having moved from onsite servers to the clown, we are popular with people who are into repatriation, self-hosting, and data sovreignty. That does have an impact on how we deliver the software. Obviously it makes no sense to go the SaaS route, "just put it in the clown and let people sign up for accounts". Our users want the software and have their own opinion about how to run it. So we want to know from the audience, what are you looking for and how can we continue making it easier to deploy.
Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
I know my vote does not count ( and i have mentioned it before ), but in general prefer native installs over containers ( be it docker, jails, whatever ). For separation i use VMs, its 100% separate that way. I just prefer to work with 'native' OS installs, that are truly isolated.
Of course if there is no other option for a particular piece of software for whatever reason, ill use docker, but not by preference.
Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
Being completely honest, I'm a total noob when it comes to docker, and have always had a poor experience with it, so, I just go native.
My desire to run the software has helped me continue to learn the nature of modern *nix systems, since I'm still somewhat of a novice with them.
So basically a case of carefully picking my battle, if that makes sense?
Subject: Re: All recently reported bugs are likely fixed in Citadel 1007
I think if I had a choice, I'd love to just get a modern version of Citadel into the debian repositories (which would then cascade out to ubuntu and other derivatives) so people could just grab the package and go. And we used to have such packages available. Unfortunately they get out of date very quickly, which doesn't work well here. Also there is a requirement for packages to be FHS compliant. We used to have a FHS installation mode but it added so much complexity and bugginess to the system that we eventually dropped it.
So today, the only real choices are the build script and the Docker container.
Both work reasonably well but I'd love to make it even easier.
Subject: Citserver crash "malloc.c:2379: sysmalloc: Assertion"
Hello everyone,
I don't know the reason yet and I'm not sure how to reproduce the problem bu If you can guide me I'll try to provide more information. For now, I can say that while I'm asleep ( isn't it always like that :) ) citserver crashes with the following log. Then it restarts itself and crashes again. This continues. I hope you can help me. Thank you very much in advance.
First Crash Logs
{"log":"citserver[3664]: msgbase: fixed_output_pre() type=\u003cmultipart/mixed\u003e\n","stream":"stderr","time":"2024-12-03T18:15:13.77452087Z"}
{"log":"citserver[3664]: msgbase: fixed_output() part 1: (text/html) (107493 bytes)\n","stream":"stderr","time":"2024-12-03T18:15:13.77474904Z"}
{"log":"citserver[3664]: ZBO2 SELECT Inbox\n","stream":"stderr","time":"2024-12-03T18:15:13.775558266Z"}
{"log":"citserver[3664]: ---- Looking up [SELECT] -----\n","stream":"stderr","time":"2024-12-03T18:15:13.775570699Z"}
{"log":"citserver[3664]: Found.\n","stream":"stderr","time":"2024-12-03T18:15:13.77557505Z"}
{"log":"citserver[3664]: \u001b[33mimap: imap_roomname(Inbox) returned(ret=0, floor=0, is_mailbox=1, roomname=Mail)\u001b[0m\n","stream":"stderr","time":"2024-12-03T18:15:13.775579122Z"}
{"log":"citserver[3664]: imap_do_expunge() called\n","stream":"stderr","time":"2024-12-03T18:15:13.775583578Z"}
{"log":"citserver[3664]: room_ops: 0000000016.Mail : 1 seen of 1 total messages, oldest=88, newest=88\n","stream":"stderr","time":"2024-12-03T18:15:13.775587407Z"}
{"log":"citserver[3664]: IMAP command completed in 0.349 seconds\n","stream":"stderr","time":"2024-12-03T18:15:13.775591427Z"}
{"log":"citserver[3664]: bnBzdXBwb3J0QGRhZmFiZXQuY29t\n","stream":"stderr","time":"2024-12-03T18:15:13.804031904Z"}
{"log":"citserver[3664]: user_ops: CtdlLoginExistingUser(****@****)\n","stream":"stderr","time":"2024-12-03T18:15:13.804070642Z"}
{"log":"citserver[3664]: internet_addressing: directory key is \u003c****@****\u003e\n","stream":"stderr","time":"2024-12-03T18:15:13.80422317Z"}
{"log":"citserver[3664]: internet_addressing: directory alias \u003c****@****\u003e to \u003c****-****\u003e\n","stream":"stderr","time":"2024-12-03T18:15:13.804246595Z"}
{"log":"citserver[3664]: Recipient #0 of type 2 is \u003c****-****\u003e\n","stream":"stderr","time":"2024-12-03T18:15:13.804268809Z"}
{"log":"citserver[3664]: internet_addressing: validate_recipients() = 1 local, 0 room, 0 SMTP, 0 error\n","stream":"stderr","time":"2024-12-03T18:15:13.804319842Z"}
{"log":"malloc(): invalid next size (unsorted)\n","stream":"stderr","time":"2024-12-03T18:15:13.806072112Z"}
{"log":"ctdlvisor: pid=3664 exited, status=134, exitcode=0\n","stream":"stderr","time":"2024-12-03T18:15:14.269828826Z"}
{"log":"ctdlvisor: citserver crashed on signal 6\n","stream":"stderr","time":"2024-12-03T18:15:14.269871183Z"}
{"log":"ctdlvisor: citserver running on pid=5420\n","stream":"stderr","time":"2024-12-03T18:15:14.269950552Z"}
{"log":"ctdlvisor: executing citserver\n","stream":"stderr","time":"2024-12-03T18:15:14.269967024Z"}
Second Crash Logs
{"log":"citserver[5420]: test: module is disabled\n","stream":"stderr","time":"2024-12-03T18:15:46.022969103Z"}
{"log":"citserver[5420]: extensions: init test\n","stream":"stderr","time":"2024-12-03T18:15:46.022999481Z"}
{"log":"citserver[5420]: extensions: init upgrade\n","stream":"stderr","time":"2024-12-03T18:15:46.023012507Z"}
{"log":"citserver[5420]: extensions: init vcard\n","stream":"stderr","time":"2024-12-03T18:15:46.023041989Z"}
{"log":"citserver[5420]: extensions: init wiki\n","stream":"stderr","time":"2024-12-03T18:15:46.023091718Z"}
{"log":"citserver[5420]: extensions: init xmpp\n","stream":"stderr","time":"2024-12-03T18:15:46.02310597Z"}
{"log":"citserver[5420]: extensions: init netconfig\n","stream":"stderr","time":"2024-12-03T18:15:46.023140815Z"}
{"log":"citserver[5420]: extensions: finished initializing modules (threading=1)\n","stream":"stderr","time":"2024-12-03T18:15:46.023161433Z"}
{"log":"webcit[9]: language found: en_US\n","stream":"stderr","time":"2024-12-03T18:15:46.230470541Z"}
{"log":"citserver[5420]: sysdep: new client socket 32\n","stream":"stderr","time":"2024-12-03T18:15:46.231069354Z"}
{"log":"citserver[5420]: fulltext: indexing started. msgs 110407--110408\n","stream":"stderr","time":"2024-12-03T18:15:46.231081849Z"}
{"log":"citserver[5420]: context: session (citadel-UDS) started from () uid=-1\n","stream":"stderr","time":"2024-12-03T18:15:46.23108641Z"}
{"log":"webcit[9]: Client is at ::ffff:172.23.34.2\n","stream":"stderr","time":"2024-12-03T18:15:46.232542646Z"}
{"log":"citserver[5420]: [(not logged in)(0)] MSGP application/x-citadel-delivery-list|text/calendar|application/ics|text/vnote|text/x-vcard|text/vcard|text/html|text/plain|text/x-citadel-variformat|text/x-markdown\n","stream":"stderr","time":"2024-12-03T18:15:46.232643436Z"}
{"log":"citserver[5420]: [(not logged in)(0)] MESG hello\n","stream":"stderr","time":"2024-12-03T18:15:46.23277837Z"}
{"log":"webcit[9]: HTTP: 200 [11.013566] GET \n","stream":"stderr","time":"2024-12-03T18:15:46.232873461Z"}
{"log":"citserver[5420]: msgbase: CtdlFetchMessage(110408, 1)\n","stream":"stderr","time":"2024-12-03T18:15:46.233912312Z"}
{"log":"citserver[5420]: fulltext: ft_index_message() adding msg 110408\n","stream":"stderr","time":"2024-12-03T18:15:46.234223191Z"}
{"log":"citserver[5420]: msgbase: CtdlOutputPreLoadedMsg(TheMessage=not null, 0, 0, 0, 1\n","stream":"stderr","time":"2024-12-03T18:15:46.23426493Z"}
{"log":"citserver[5420]: msgbase: fixed_output_pre() type=\u003cmultipart/mixed\u003e\n","stream":"stderr","time":"2024-12-03T18:15:46.234434983Z"}
{"log":"citserver[5420]: msgbase: fixed_output() part 1: (text/html) (107493 bytes)\n","stream":"stderr","time":"2024-12-03T18:15:46.234735738Z"}
{"log":"citserver: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) \u0026\u0026 old_size == 0) || ((unsigned long) (old_size) \u003e= MINSIZE \u0026\u0026 prev_inuse (old_top) \u0026\u0026 ((unsigned long) old_end \u0026 (pagesize - 1)) == 0)' failed.\n","stream":"stderr","time":"2024-12-03T18:15:46.266152398Z"}
{"log":"ctdlvisor: pid=5420 exited, status=134, exitcode=0\n","stream":"stderr","time":"2024-12-03T18:15:46.271281561Z"}
{"log":"ctdlvisor: citserver crashed on signal 6\n","stream":"stderr","time":"2024-12-03T18:15:46.271294147Z"}
{"log":"ctdlvisor: citserver running on pid=5423\n","stream":"stderr","time":"2024-12-03T18:15:46.271388146Z"}
{"log":"ctdlvisor: executing citserver\n","stream":"stderr","time":"2024-12-03T18:15:46.271400291Z"}
I have these ports open on the router, but only two work: 587 and 110. Both reply to a telnet request, but 587 will not use encryption.
Ports 25, 465, 995, 143, and 993 do not work with my email program, Outlook 2019, and do not respond to a telnet request.
What do I have set wrong?
Night
The ports are open in the server's firewall.
I have these ports open on the router, but only two work: 587 and 110. Both reply to a telnet request, but 587 will not use encryption.
Ports 25, 465, 995, 143, and 993 do not work with my email program, Outlook 2019, and do not respond to a telnet request.
What do I have set wrong?
Night
Netstat gives me this? Why are only tcp6 open?
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:http-alt 0.0.0.0:* LISTEN
tcp 0 0 localhost:ipp 0.0.0.0:* LISTEN
tcp 0 0 localhost:spamd 0.0.0.0:* LISTEN
tcp 0 0 localhost:6060 0.0.0.0:* LISTEN
tcp6 0 0 localhost:ipp [::]:* LISTEN
tcp6 0 0 localhost:spamd [::]:* LISTEN
tcp6 0 0 [::]:504 [::]:* LISTEN
tcp6 0 0 [::]:imap2 [::]:* LISTEN
tcp6 0 0 [::]:pop3 [::]:* LISTEN
tcp6 0 0 [::]:nntp [::]:* LISTEN
tcp6 0 0 [::]:smtp [::]:* LISTEN
tcp6 0 0 [::]:submission [::]:* LISTEN
tcp6 0 0 [::]:xxxx [::]:* LISTEN
tcp6 0 0 [::]:xxxx [::]:* LISTEN
tcp6 0 0 [::]:xmpp-client [::]:* LISTEN
The ports are open in the server's firewall.
I have these ports open on the router, but only two work: 587 and 110. Both reply to a telnet request, but 587 will not use encryption.
Ports 25, 465, 995, 143, and 993 do not work with my email program, Outlook 2019, and do not respond to a telnet request.
What do I have set wrong?
Night
Netstat gives me this? Why are only tcp6 open?
Because a tcp6 listener will accept incoming connections on both IPv6 and IPv4.
At least, that's the default behavior on most operating systems. OpenBSD is the exception.
Ports 25, 465, 995, 143, and 993 do not work with my email
program, Outlook 2019, and do not respond to a telnet request.
Possibly some other program on your server is listening on those ports?
Ports 25, 465, 995, 143, and 993 do not work with my email
program, Outlook 2019, and do not respond to a telnet request.
Possibly some other program on your server is listening on those ports?
I just installed the latest OS on the Raspberry Pi 5. The only things on the Raspberry Pi 5 are the OS and Citadel. I just redid the server today, with the same results. I can run netstat or ss, about the same, after a fresh install to check if something is listening to those ports.
I have to use 110 with no encryption (pop), and 587 (smpt) in auto encryption. Those are the only ports that seem to work. And the really strange thing is that the email sets up as if it were IMAP??? Sets up all the folders of citadel. I really don't get that part.
Night
Netstat gives me this? Why are only tcp6 open?
Because a tcp6 listener will accept incoming connections on both IPv6 and IPv4.
At least, that's the default behavior on most operating systems. OpenBSD is the exception.
Thank you, I was not aware of that.
Night
Ok, instead of netstat, try this command:
ss -ltup
`ss` is the newish replacement for `netstat`. L for listening ports, TU for TCP and UDP, P to tell us the process attached to each port. Post the output. That'll tell us for sure whether it really is Citadel Server that is listening (or not listening) on those ports.
Ok, instead of netstat, try this command:
ss -ltup
`ss` is the newish replacement for `netstat`. L for listening ports, TU for TCP and UDP, P to tell us the process attached to each port. Post the output. That'll tell us for sure whether it really is Citadel Server that is listening (or not listening) on those ports.
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN
tcp 0 0 localhost:ipp 0.0.0.0:* LISTEN
tcp6 0 0 [::]:ssh [::]:* LISTEN
tcp6 0 0 localhost:ipp [::]:* LISTEN
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN
tcp 0 0 localhost:ipp 0.0.0.0:* LISTEN
tcp6 0 0 localhost:ipp [::]:* LISTEN
tcp6 0 0 [::]:submission [::]:* LISTEN
tcp6 0 0 [::]:ssh [::]:* LISTEN
tcp6 0 0 [::]:smtp [::]:* LISTEN
tcp6 0 0 [::]:nntp [::]:* LISTEN
tcp6 0 0 [::]:pop3 [::]:* LISTEN
tcp6 0 0 [::]:imap2 [::]:* LISTEN
tcp6 0 0 [::]:504 [::]:* LISTEN
tcp6 0 0 [::]:xmpp-client [::]:* LISTEN
tcp6 0 0 [::]:xxxxx [::]:* LISTEN
tcp6 0 0 [::]:xxxxx [::]:* LISTEN
Raspberry Pi 5 Model B Rev 1.0
Debian Linux 12 (bookworm)
total used free shared buff/cache available
Mem: 8050 576 6819 22 762 7474
Swap: 511 0 511
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 0.0.0.0:36492 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:*
udp UNCONN 0 0 *:44250 *:*
udp UNCONN 0 0 *:mdns *:*
tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
tcp LISTEN 0 128 127.0.0.1:ipp 0.0.0.0:*
tcp LISTEN 0 5 *:imap2 *:*
tcp LISTEN 0 5 *:nntp *:*
tcp LISTEN 0 5 *:pop3 *:*
tcp LISTEN 0 128 [::]:ssh [::]:*
tcp LISTEN 0 5 *:smtp *:*
tcp LISTEN 0 5 *:504 *:*
tcp LISTEN 0 5 *:submission *:*
tcp LISTEN 0 5 *:xmpp-client *:*
tcp LISTEN 0 100 *:xxxx *:*
tcp LISTEN 0 100 *:xxxx *:*
tcp LISTEN 0 128 [::1]:ipp [::]:*
Dear All,
I am concatenating my rules.
I want to have a rule that in some conditions it forwards an email to several emails. Then I forward with a string of 4 emails, separated by commas, and only it is received in 3 of these emails. Are the forward limited to 3 emails for each rule? Can it please be increased for more number of emails?
Some time ago you said that it will be a major release until the end of the year. Will it be? And will it solve the missing icons when webcit is accessed by Apache Proxy? (see please some posts before from me)
Thanks,
Luís Gonçalves.
"I am concatenating my rules.
I want to have a rule that in some conditions it forwards an email to several emails. Then I forward with a string of 4 emails, separated by commas, and only it is received in 3 of these emails. Are the forward limited to 3 emails for each rule? Can it please be increased for more number of emails?"
Seems not a problem of Citadel.
1st port check was freshly installed.
2nd was a fresh installation of citadel
3rd was a different port check.
I've also noticed one other weird thing. When I go to administration and press restart, the server shuts down but doesn't restart. I have to reboot the system.
Thank you for helping
Night