Please wait...
0 files
Subject: Re: maximum password length exceeded on setup
Hi, i am totally new to this (installed it yesterday) but found in the FAQ that you can reset the password by ssh to your machine and run the setup utility
which will be in /usr/local/citadel/setup for Easy Install or /usr/lib/citadel-server/setup if you have the .deb packages
Subject: Re: maximum password length exceeded on setup
How to reset the password on the admin account with a ssh connect to the server.
I've googled and you have no idea how many things out there are called "citadel". Steam apparently have a game and it swamps the search hits for overriding passwords, even if you put a -steam qualifier.
I did find a very belated note out there that the maximum character length is 32 characters, which may or may not be outdated information. The shortest maximum I've ever seen was 9 characters on ICQ after the protocol became popular in Russia, presumably someone running the network was trying hard not to get arrested.
Anyway, I fell head-first into the trap and I don't know how to climb out. I could re-run the easy install but I thought I'd ask and then go for a walk.
Whaaa! ....my third post and the wheels are coming off :-) i replied to a question without quoting and was suddenly lost disorientated , forlorn , now i see the question was from a year ago ...ho ho!
Hi again denizens of this Citadel! Hoping to make use of Citadel as a functioning mail server after 'google workspace freebiee' closes down.
Successfully 'easy installed' on deb , DNS'sed and certbotted but https -p 443 is not happening for me , there does not seem to be instructions about required ports in the documentation but it seems https is not being forced.
this hoping someone will please chip in.
I have not been around for a while, seams like my account was removed.
I have to do some coding work, and would like to get access with my original user name.
Following is a post of mine:
https://uncensored.citadel.org/readfwd?go=CitaNews?start_reading_at=4055627
These are the thinks I have coded for citadel in the past:
https://bitbucket.org/gotamer/citadelsync/src/master/
https://bitbucket.org/gotamer/citadel/src/master/
Sorry for the trouble, and thanks
TaMeR
Based on the progress we've made so far, I would say it is just a
matter of weeks before we push out a new version that handles the
FreeIPA schema properly.
This is kind of fun -- we're using the FreeIPA public demo/test server for this development process, and I just logged in to my dev box and saw a bunch of new users. Someone, somewhere in the world, is testing out FreeIPA, and every user they create is getting created on Citadel.
So there's some progress :)
Attention: erol.kahraman and anyone else attempting to use Citadel with FreeIPA LDAP server:
Please upgrade to Citadel version 950, available starting 2022-apr-09 on Easy Install, and starting 2022-apr-10 on DockerHub.
We have made several changes:
1. It seems we had some deprecated OpenLDAP calls in there, which compiled cleanly but ran poorly. We have updated to the new calls.
2. We are adhering more cleanly to the POSIX schema now. Specifically:
Display name: "displayName"
Numeric user id: "uidNumber"
Auth username: objectclass=inetOrgPerson and cn=%s
To search for users: objectClass=inetOrgPerson
For those following along in Micro$oft land, their nonstandard schema is still supported:
Display name: "cn"
Numeric user id: made from a hash of "objectGUID"
Auth username: "sAMAccountName"
To search for users: objectClass=user and objectClass=person and objectClass!=computer
Give it a try! I've got my test system pointed at the FreeIPA public test/demo server. It's kind of fun to watch.
Hi,
First of all i would like to thank everyone who developed that great suite and fixed the bugs.
I downloaded and installed the new version (950) and tested it with FreeIPA. I have some issues and questions:
1. During configuration process i choose an admin user account as "admin". There is an admin account in my LDAP server. But i couldn't login with it. I realized that the admin account doesn't hava objectClass=inetOrgPerson attribute. I added the attribute with ldapmodify but the result didn't change. Is there any other restriction that i missing?
2. At the second test during configuration process i choose an admin user account as "erol.kahraman". I could login with my account. However, this time i couldn't get an Administrative privileges. There is no Administration section on main menu. How can i become administrator?
3. At the login screeen i use erol.kahraman as username from LDAP server. After i login successful i try to send an email to an other user. I try to send an email with an uid (like erol.kahraman) attribute. I realized that the emails couldn't arrived to recipient. After some tries i realized that an email addresses of an accounts are like "erol_kahraman@...". The email accounts created from Name_Surname (i think). Is there any way to configure citadel to use uid attribute for email addresses?
Attention: erol.kahraman and anyone else attempting to use Citadel with FreeIPA LDAP server:
Please upgrade to Citadel version 950, available starting 2022-apr-09 on Easy Install, and starting 2022-apr-10 on DockerHub.
We have made several changes:
1. It seems we had some deprecated OpenLDAP calls in there, which compiled cleanly but ran poorly. We have updated to the new calls.
2. We are adhering more cleanly to the POSIX schema now. Specifically:
Display name: "displayName"
Numeric user id: "uidNumber"
Auth username: objectclass=inetOrgPerson and cn=%s
To search for users: objectClass=inetOrgPerson
For those following along in Micro$oft land, their nonstandard schema is still supported:
Display name: "cn"
Numeric user id: made from a hash of "objectGUID"
Auth username: "sAMAccountName"
To search for users: objectClass=user and objectClass=person and objectClass!=computer
Give it a try! I've got my test system pointed at the FreeIPA public test/demo server. It's kind of fun to watch.
Mew mew! So I have spent the last few days working on a set of patches to make Citadel compile on FreeBSD. Tested and works on both 12.2 and 13.0.
citadel-patches-FreeBSD.tgz: patchset for all the main components: libcitadel, citadel, webcit, and textclient
install.diff : the patchset that makes install (for easyinstall) work on FreeBSD. Also brings in an automagic patching framework.
citpatch.diff : The full patchset from the root of the git repo.
I cannot guarantee that all the shell script patches are fully portable. The code patches should be portable. Perhaps some of this stuff could be done another (better) way, but this is "good enough" to make things work.
To use:
First off, follow the instructions at https://citadel.org/installing_citadel_on_freebsd.html
Place the attached files in the same folder where you downloaded the scripts.
Patch the things:
patch -i install.diff
doas mkdir -p /usr/local/ctdlsupport/ospatch
doas tar -xf citadel-patches-FreeBSD.tgz -C /usr/local/ctdlsupport/ospatch
Build it! This is the easy part.
chmod +x install
doas ./install
This patch to the install script supports the ability to use FreeBSD's pkg command to install all the required stuffs. I tried to be thorough on this, but I may have missed a few packages. Also, it might be a better idea to use origins (like devel/gcc) instead of just package names since pkg now supports that. When the installer asks "Do you want Easy Install to attempt to install your OS dependencies?" just press Y and hit enter. It'll work.
Once built, just prep your system and run Citadel.
chmod +x citserver.sh webcit.sh
doas cp *.sh /usr/local/etc/rc.d/
doas sysrc citadel_enable="YES"
doas sysrc webcit_enable="YES"
doas service citadel start
doas service webcit start
Mew mew! So I have spent the last few days working on a set of patchesto
make Citadel compile on FreeBSD. Tested and works on both 12.2 and 13.0.
This is extremely welcome -- thank you for posting the patches. Just so you're aware, I have to get through a bunch of things this weekend so it'll be a few days before I can look at the patches and work them into the build.
But -- thank you!
There's going to be an update to this. I posted this after I got it to build, but before I got it running. Now that I have it running, I need to work on making an update. Would you like an updated patchset or a secondary patchset?
This is extremely welcome -- thank you for posting the patches. Just so you're aware, I have to get through a bunch of things this weekend so it'll be a few days before I can look at the patches and work them into the build.
But -- thank you!
There's going to be an update to this. I posted this after I got it to
build, but before I got it running. Now that I have it running, I needto
work on making an update. Would you like an updated patchset or a secondary
patchset?
Since it's going to be a couple of days anyway, just send an updated patch set with everything in it, that can be applied against the current git master.
Thanks!
Subject: Patches for FreeBSD ROUND TWO: FIGHT!
Mew mew everykitty! This is the second round of patches for FreeBSD. This time, I'm primarily focusing on patching at the git-repo level.
As with the previous patch, 100% portability is not guaranteed. Something to work on. At least the bulk of the work is done.
From here on out, the only patches I post here will be geared for the git repo. For the "ospatch" file and full instructions to install, you'll have to go to the Killer Kittens citadel. Thankfully, I'm keeping it all in one place: https://ladyserenakitty.com/dotgoto?room=Citadel
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