Please wait...
0 files
Subject: Re: Patches for FreeBSD ROUND TWO: FIGHT!
1. Citadel Server
As far as I can tell, there are no problems here. It built and ran fine on Linux.
2. WebCit (webcit-classic, not webcit-ng)
During the build there were a lot of complaints from get_ical_data.sh that it couldn't find gsed. I see that the change from sed to gsed in the patch isn't a FreeBSD conditional. We'll have to work this out. It still runs, but maybe the calendar stuff isn't quite right.
3. Text client (BBS client)
The linker can't find libiconv. Honestly I'm not quite sure how it's building on Linux without it, but we'll have to work that out too.
If you're willing to stick with us on this, I'll give you access to the Citadel Development room and we can continue the build conversations there instead of mucking up the support forum?
Subject: Re: Patches for FreeBSD ROUND TWO: FIGHT!
1. I didn't have to modify any scripts, just C code.
2. I had to modify the shell scripts to make it work on FreeBSD. I had to install gsed because one of the regexes went pathological on regular sed (BSD sed).
3. Interesting, so my fix to make it find libiconv on FreeBSD broke it on linux.
I've been considering half-forking, that is, writing a whole new implementation. A competing product, which would halp the Citadel commewnity overall (competition breeds innovation). I'll stick around and halp even if I do start my own implementation of the Citadel suite/protocol. After all, the original (reference) implementation still needs to run on FreeBSD.
Maybe we can target Haiku, too (j/k, they're still in Beta).
Tue Apr 19 2022 20:23:40 EDT from IGnatius T Foobar Subject: Re: Patches for FreeBSD ROUND TWO: FIGHT!All righty meow, here's what we've got so far. I've applied citpatch.diff "as is" to git master, so your changes are in place and it's time to figure out how to get everything working nicely on both Linux and FreeBSD.
1. Citadel Server
As far as I can tell, there are no problems here. It built and ran fine on Linux.
2. WebCit (webcit-classic, not webcit-ng)
During the build there were a lot of complaints from get_ical_data.sh that it couldn't find gsed. I see that the change from sed to gsed in the patch isn't a FreeBSD conditional. We'll have to work this out. It still runs, but maybe the calendar stuff isn't quite right.
3. Text client (BBS client)
The linker can't find libiconv. Honestly I'm not quite sure how it's building on Linux without it, but we'll have to work that out too.
If you're willing to stick with us on this, I'll give you access to the Citadel Development room and we can continue the build conversations there instead of mucking up the support forum?
HI,
I just installed Citadel on the raspberry PI 3+ but it doesn't work: when starting the citserver (either from simple command line or via service ) it fails, here is what I can see in the logs:
sudo systemctl status citadel.service
● citadel.service - LSB: control citadel server start at boot time
Loaded: loaded (/etc/init.d/citadel; generated)
Active: active (exited) since Wed 2022-04-20 10:13:37 CEST; 2min 9s ago
Docs: man:systemd-sysv-generator(8)
Process: 5340 ExecStart=/etc/init.d/citadel start (code=exited, status=0/SUCCESS)
CPU: 3.572s
apr 20 10:13:36 NAS systemd[1]: Starting LSB: control citadel server start at boot time...
apr 20 10:13:37 NAS systemd[1]: Started LSB: control citadel server start at boot time.
apr 20 10:13:40 NAS citserver[5347]: db: cursor still in progress on cdb 00: attempt to write during r/o cursor
eolKit: you didn't mention how you installed Citadel -- from a repository, using Easy Install, or as a container? Also what OS and architecture (ARM32 or ARM64) you're running on?
If it's a brand new installation, that message suggests that you somehow got two citservers running at once, which shouldn't happen because there are locks and things that prevent that.
Subject: Re: Patches for FreeBSD ROUND TWO: FIGHT!
Meow meow and meow and etc. etc. LadySerenaKitty posted on another site some ideas for future Citadel development, and I wanted to address them.
You might not realize how on-point you were with some of those things -- either as things that have been done in the past or things planned for the future. Let me see if I can address them one at a time. I don't have your original post up right now so I'll paraphrase.
1. Build an alternative, but compatible, implementation of the Citadel System that is more modular.
You might have noticed in the protocol documentation that there are provisions for this, to identify client and server implementations to each other so each end can have some sort of idea what's on the other end. Obviously it'll be better if every server command is known to work a certain way everywhere, and avoid "user agent" weirdness, but yes, this can be accomodate.
After all, there have been over 100 variants of Citadel over the last 40 years (yes, the original implementation was brought up in December 1981, making Citadel one of the oldest open source projects anywhere) and it's a long tradition.
As for modularity -- if that's your thing, then go for it! Do be aware that we've done this sort of thing in the past, with loadable modules that can be snapped in and out. What we found was that it created a lot of headaches because the build system didn't work exactly the same on every version of unix, and we spent a lot of time wrangling that instead of building cool new functionality. So we moved it back to a monolithic build, but the modularity lives on in the form of a fairly clean separation between the server core and its extensions. Over the years I've had a lot of focus on making the system easy to install, which often takes the form of dumbing down the build as much as possible. If we were building from a greenfield today, there would probably be a lot of containers. :)
2. Clustered installation of Citadel (mortar)
It was only within the last two years that we moved away from this. WebCit and Citadel Server could run on different machines, and you could load balance a bunch of WebCit servers, very early-2000s style deployment. We also had the ability to run multiple servers that could share Internet email domains, so if a message arrived on any one of them it would go to the home server of that user. What we found in practice is that by the late 2010s nobody was using either of these features; nobody noticed when we removed them; and thousands of lines of cruft came away from the code.
I think there might still be some interest in "high availability" in the classic sense, and in the future it would be cool to explore things like replicating the database in a master/slave configuration and giving the clients the ability to automatically fail over when the active node goes away, things like that.
3. Federated clusters and constellations of Citadel (netadel / citanet)
Sharing rooms and email over a native Citadel network is a *classic* application of Citadel, dating way back to the days of dialup and long distance modem calls. So you're pretty much spot on here. I also agree with your assertion that relays need to become a thing of the past. We removed the native networking stuff a couple of years ago after the last few connections went away -- mainly because I am envisioning something even bigger:
There are some nascent efforts to federate what I like to call the "sovereign web" -- the multitude of independent sites not controlled and censored by Big Tech. Rather than start new protocols I'd like to explore the existing ones used by things like mastodon and opensocial, and see how we can potentially integrate Citadel into those networks.
The idea of bypassing SMTP for Citadel-to-Citadel mail is something we've done before, but only when the two nodes have previously arranged it. I can envision using some sort of larger system and we can definitely explore that.
After all, when two Apple users send text messages to each other using iMessage, it figures that out and bypasses the SMS message center. The idea of establishing a higher level of trust than that which is present on the public Internet is an interesting one.
Lots of great ideas, all it takes is someone to try them out!
Subject: Re: Patches for FreeBSD ROUND TWO: FIGHT!
My idea for modularity isn't using a plug-in architecture, instead it's running a completely separate daemon process for each protocol.
I am running Citadel server v 950 on a Raspberry Pi. All mail is local. Nothing is sent to the outside. If I attach a file, say 33 KB, to a mail message and send it, the person receiving the file gets a file of 7.7 KB and it is corrupted. In several test of various size files, each comes out the other end corrupted and with a size of 7.7 KB.
I have look thru the knowledge base but I don't see any reference to anything relating to attachments.'
Any thoughts on how to resolve the issue and get a usable file to the recipient?
Bob S
Sequim, WA
Will not send attachments with Ubuntu OS either.
Bob
Sequim, WA
"What OS are you running on the Pi, and is it 32 or 64 bit, how much installed RAM, how much swap is configured, and how did you install Citadel?"
What OS... I tried Buster, 32 bit, on a 32GB SD card, I believe the Pi has 256 MB of RAM. I did not enable any additional swap space, I used the easy install.
I also tried an install (on the same Pi board) of Ubuntu 20.4, 32 bit on a 32GB SD card, I believe the Pi has 256 MB of RAM. I did not enable any additional swap space, I used the easy install.
Bob
Sequim, WA
Currently using the Ubuntu 20.4 OS. Typing sudo free -h I get:
RAM total 917mi, used 136mi, free 144mi, shared 3.0mi, buffer 636 mi, available 757
Swap = 0
Bob
Sequim, WA
Put Ubuntu 20 on an old PC along with Citadel loaded from the easy install. Initially I noticed the same thing. I would get kicked out of the application about 80% of the time as soon as I posted an attachment. I began to notice if I waited for 5 to 10 seconds after i did the attachment before closing the page and going back to the email, putting some words in the email, waiting another 5 seconds, then click send, the mail and attachment would go almost 100% of the time.
i will go back to the RPi and see if the same scenario plays out when putting the delays in the process.
Bob
Sequim, WA
I always assumed it had something to do with memory management, but maybe you're onto something and it's a race condition. Will look into this more!
Just as a quick update ... so far, what I have been able to reproduce is that I get s software crash while attempting to upload large attachments on a Pi. The debugger says its crashing inside the base64-encode library. Does this sound like what you miht be experiencing? Incoming mail from the outside would be encoded somewhere else, so it wouldnt crash the library.
Size of the attachment did not make any difference. I could reproduce it 100% of the time if I did an attachment, quickly hit close and then, again, quickly hit send. Also, leave the document blank with no words.
Bob
Hi
I have a problem using the Citadel Easy Intall script on both Raspberry Pi4 (Raspian) and OdroidC2 (Ubuntu). Keep getting error /usr/bin/ld: cannot find -liconv
collect2: error: ld returned 1 exit status
I managed to install it previously without issues? Any suggestions?
I'm getting the same thing on a brand new install of Devuan;
gcc citadel.o citadel_ipc.o client_chat.o client_passwords.o commands.o ipc_c_tcp.o messages.o rooms.o routines2.o routines.o s
creen.o tuiconfig.o -L/usr/local/ctdlsupport/lib -Wl,--rpath -Wl,/usr/local/ctdlsupport/lib -lssl -lcrypto -lz -liconv -lcitad
el -o citadel
/usr/bin/ld: cannot find -liconv
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:21: citadel] Error 1
Citadel Easy Install is aborting.
The last few lines above this message may indicate what went wrong.
Linux Debian 11.1( 5.10.0-14-amd64 x86_64)