After checking "allow anonymous guest access" in the Administrator, Access tab, running some test, and then unchecking it - Citadel could not see any rooms. It was displaying just the text, "room not found" on a white page. 

I did ./sendcommand down after which,  a ./sendcommand up said "socket can't be reached". I did a systemctl reboot and everything came back up - but now the server is responding very slow (it seems like it is having problems with SSL connections failing and retrying) and the rss feeds are not updating. I tried deleting and recreating a room with an rss feed, and it made no difference. Any suggestions? 

Dec  8 11:03:25 tsbbs citserver[5071]: citserver[5071]: rssclient: using libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3

Dec  8 11:03:25 tsbbs citserver[5071]: citserver[5071]: Existing database version on disk is 929

Dec  8 11:03:25 tsbbs citserver[5071]: rssclient: using libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3

Dec  8 11:03:25 tsbbs citserver[5071]: Existing database version on disk is 929

Dec  8 11:03:26 tsbbs citserver[5071]: citserver[5071]: netspool: InspectQueuedRoom(Reddit MiSTer rss)

Dec  8 11:03:26 tsbbs citserver[5071]: netspool: InspectQueuedRoom(Reddit MiSTer rss)

Dec  8 11:03:54 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:03:54 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:04:22 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:04:22 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:04:50 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:04:50 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:05:18 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:05:18 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:05:46 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:05:46 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:06:14 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:06:14 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:06:42 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:06:42 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

root@tsbbs:/home/bbs# Dec  8 11:04:50 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

bash: Dec: command not found

root@tsbbs:/home/bbs# Dec  8 11:04:50 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

bash: Dec: command not found

Dec  8 11:06:14 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:06:14 tsbbs citserver[5071]: rssclient: failed to load feed: Timeout was reached

Dec  8 11:06:42 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

root@tsbbs:/home/bbs# Dec  8 11:05:18 tsbbs citserver[5071]: citserver[5071]: rssclient: failed to load feed: Timeout was reached

Good evening,I write in case someone can help me solve a serious problem:

I have been using citadel for over a year ... I have never had any major problems but from today it does not work and I see this error:

db: cursor still in progress on cdb 02: attempt to write during r / o cursor.

Version 921 (build d0c353575)

OS linux Debian GNU / Linux 9.6 (stretch)

telnet no longer works:telnet 127.0.0.1 25Trying 127.0.0.1 ...telnet: Unable to connect to remote host: Connection refused

P.S. sorry for my english

Yeah, I got that part working. Haven't figured out how to have it just auto-log in with a blank PW... so after connecting to cit@wallofhate.com via SSH, they have to type in cit for the password. 

Got it to redirect to the wiki page on my test system - but can't get it to redirect on my production machine. The test system has permissions pretty much wide open - but every time I rebuild it, I get a little better at building a Citadel. I've figured out pretty much where everything is and how it all interacts at this point. 

Eventually I basically want the test machine to be a hot spare for the production one. 

Tue Dec 08 2020 14:14:34 EST from IGnatius T Foobar @ Uncensored Subject: Re: bbs@uncensored.citadel.org

How do you set up BBS to not require a password and launch the
textclient automatically from a SSH session? 

You create an account called "bbs" and make its shell /usr/local/citadel/citadel instead of /bin/bash

So, I discovered something that seems related to attachments and file uploads on Raspbian... 

So, there isn't a default ROOT account on Raspbian. The default account Pi needs to sudo for everything and can't SU - and I think root is disabled. 


Along those lines, there is no access to /usr/local/citadel/files 

But... once I migrated the database from the Pi to Debian running on the i5 - historical attachments that were inaccessible and/or corrupted on the Pi are now working fine on the Debian install - for the most part. I don't think I got everything over - but I went back and looked at historical messages that had attachments that were "corrupted" or just little blank empty boxes on the Pi - and now they're files and if I click on them they open. 

So - this seems like a permissions issue with the /files directory on the Pi? 

Both Uncensored and The Sanitarium occasionally do this when "Goto"ing to a new room - and this is basically the screen I was getting when I was trying to redirect to the Wiki landing page I made: 


Occasionally Citadel seems to be unable to find what it was looking for. 

I looked through the FAQ and did some google-fu, I believe I've seen the answer but want to check with the support forum before moving on.

I'm trying to replace an ancient windows mailserver setup with a new raspi4 and citadel. I initially chose this email package because I saw the multi domain function.  From what I've sorted so far with it installed, the citadel users are unique names and can receive on any domain instead of per domain. I have 4 domains in my group and 3 of them have sales@domain.com accounts for example. I'm assuming there is not a way for them to have the same email username and go to unique citadel users accounts at different domains from what I've read now?

Thanks!

DDZ

I'll look into this. That would be awesome. 

Wed Dec 09 2020 22:24:52 EST from IGnatius T Foobar @ Uncensored Subject: Re: bbs@uncensored.citadel.org

Yeah, I got that part working. Haven't figured out how to have it
just auto-log in with a blank PW... so after connecting to

There should be a "permit empty passwords" configuration directive in your SSH server config.

Yeah. I changed it on test... made sure it didn't do anything terrible to the machine, but didn't fully test it - I don't have SSH fully configured there for default log in with an account with blank for a password. 


So, I tried it on my main box - and when I edit it in sshd_config - allow blank passwords, then delete the PW on the SSH account for Citadel - it still wants a password at login. It isn't the end of the world, people can ssh in, I just have to publish the password for the account... so user:cit pw:cit

I'd rather have it transparent to the end user - but... I'm not that good at Linux. :) 

Thu Dec 10 2020 10:58:36 EST from ParanoidDelusions @ Uncensored Subject: Re: bbs@uncensored.citadel.org

I'll look into this. That would be awesome. 

Wed Dec 09 2020 22:24:52 EST from IGnatius T Foobar @ Uncensored Subject: Re: bbs@uncensored.citadel.org

Yeah, I got that part working. Haven't figured out how to have it
just auto-log in with a blank PW... so after connecting to

There should be a "permit empty passwords" configuration directive in your SSH server config.

 

Evidently the entry made in /etc/resolv.conf does not stay permanently in Debian. Settings from initscripts or NetworkManager or systemd-resolved will evidently overwrite changes written to resolv.conf.

So, when I built the machine, on a different network, I set up that network and its DNS servers through NetworkManager during the GUI install build of Debian. 

Then when I moved it over, I edited /etc/resolv.conf to change to the VPN ISP DNS servers. 

Then when I rebooted, it reverted back to the other DNS servers, my regular consumer ISP DNS servers - which reject DNS client sessions from outside their network. 

So, I had no DNS. That is why RSS feeds quit. 

I figured this out when I read an article on changing DNS servers - and trying to install resolvconf - the server couldn't reach the Debian repos. 

So then I pinged google and others, and got no response - and the game was afoot. 

This is the article that helped me: 

https://www.tecmint.com/set-permanent-dns-nameservers-in-ubuntu-debian/

It wasn't the webcit client - it was Debian and Linux moving my cheese. I don't know how long ago this cheese was moved - it might have been so long this seems obvious to anyone who has been keeping up with Linux development - but it caught me unaware - so I thought I'd share the fix. 

Also, the BBS had been running dog slow for the last 4 or 5 days since the reboot, and I couldn't figure it out. Things are much snappier now - so I'm assuming that was the problem. Don't know why domain name resolution would make Citadel run slow on rendering pages and responding - but I guess it was talking to SOMEONE by name and not getting there. Hopefully that was the case, anyhow. 

I swear to God... one time out of 100, for some reason - something will go wrong, and I'll end up at a blank page, with "page not found" displayed in the upper left corner of the browser in plain black text. And one time out of 10, I'll be logged out when this happens, and I'll hit F5 to refresh the page... 

And it will come back up and land at the Wiki page - like Clark Griswald's Christmas Tree lights coming on and blinding the Yuppie neighbors. A brief moment of, "YES! YES! That is EXACTLY what it is fsckin' supposed to do when you first land on The Sanitarium! That is what I want!" 

And then, it is gone, and I have no idea what condition caused it to do that - and nothing I do will make it work again. 

Hi all,

I have a new Citadel install on RPi 3. Everything went well and it is sending and receiving e-mail without issue when I use the web UI. However, when I try to send e-mail from a remote application (Homeseer), I get an authentication error:

Exception sending email via myserver.mydomain.org (To:destination@myemail.org, cc:destination@myemail.org, bcc:, Sub:Homeseer Native E-mail Test, Attach:) = Authentication failed.

I am using the exact same username and password I use to login into the web UI. I'm using Port 25.

I've tried setting up a new user, changing passwords, etc., but get the exact same result every time. Here is my Homeseer setup in case anyone notices anything off:

After following the instructions at: 

https://www.citadel.org/how_to_install_a_certificate_signed_by_a_recognized_certificate_authority.html

To create a self-signed certificate - I am getting the error "this site can't provide a secure connection secure.wallofhate.com uses an unsupported protocol ERR_SSL_VERSION_OR_CIPHER_MISTMATCH"

This *did* seem to fix the issue with the -g/dotgoto?=room redirect not working in a regular, unencrypted HTTP: connection. 

http://wallofhate.com:8916 now takes you to exactly the landing page I intend - I suspect if https: was working, it would work too. 


It seems like it is most likely the instructions at citadel.org discuss how to create an older, depreciated certificate that modern browsers do not support. 

Is there some modification to creating my own self-signed cert that I can use to overcome this error? 

I'm reading up - but it all seems to explain it from a client perspective, not a server side fix... 

Website documentation needs to be updated. 

openssl genrsa -out citadel.key 1024 will generate the errors I was seeing, because modern browsers consider a 1024 bit cypher key insecure. 

openssl genrsa -out citadelkey 2048 (or higher) will fix the issue. 

I'm up. The landing page is working right. RSS feeds are working right, I think... I'm going to test - the extended performance and reliability issues have driven away virtually all of my users... 

But it all seems to be working over at secure.wallofhate.com

openssl genrsa -out citadel.key 1024 

Sorry, I forgot the subject field once again. Delete the previous two messages, I've consolidated them into one message, here: 

Website documentation needs to be updated. 

openssl genrsa -out citadel.key 1024 will generate the errors I was seeing, because modern browsers consider a 1024 bit cypher key insecure. 

openssl genrsa -out citadel.key 2048 (or higher) will fix the issue. 

I'm up. The landing page is working right. RSS feeds are working right, I think... I'm going to test - the extended performance and reliability issues have driven away virtually all of my users... 

But it all seems to be working over at secure.wallofhate.com - and it did fix the issue in both HTTP and HTTPS with the redirect in webcit-http.service and webcit-https.service not working. Not sure how it was related - but fixing this fixed that. 

openssl genrsa -out citadel.key 1024 

Sat Dec 12 2020 15:49:09 EST from ParanoidDelusions @ Uncensored

After following the instructions at: 

https://www.citadel.org/how_to_install_a_certificate_signed_by_a_recognized_certificate_authority.html

To create a self-signed certificate - I am getting the error "this site can't provide a secure connection secure.wallofhate.com uses an unsupported protocol ERR_SSL_VERSION_OR_CIPHER_MISTMATCH"

This *did* seem to fix the issue with the -g/dotgoto?=room redirect not working in a regular, unencrypted HTTP: connection. 

http://wallofhate.com:8916 now takes you to exactly the landing page I intend - I suspect if https: was working, it would work too. 


It seems like it is most likely the instructions at citadel.org discuss how to create an older, depreciated certificate that modern browsers do not support. 

Is there some modification to creating my own self-signed cert that I can use to overcome this error? 

I'm reading up - but it all seems to explain it from a client perspective, not a server side fix... 

I've got a bit more information to add to this after some more troubleshooting...

I am running Citadel 929 with WebCit 926, server build 929.

I used telnet from a remote system to test SMTP authentication. I connected fine to both ports 25 and 587. Using a text-to-Base64 online converter, I was able to login using my administrator user successfully. I then used to "mail from:" command and used my administrator's Internet e-mail address - ok. I then used the "rcpt to:" command to define my target and the response come back, "You do not have permission to send Internet mail".

However, the "Permission to send Internet mail" check box is checked for all of my users. I also tried unsetting it, restarting server, and resetting it, and restarting server. Same behaviour whether the box is checked or not. Is this a bug in the UI? Is there a way to check this user setting through command line?

Thanks,

Peter