Just testing... 

Part of the problems right now seem related to the fact that I created new accounts when I moved Citadel from bare metal to the VM - and I don't think I got the permissions and group membership quite right. 

So, for example, uploads to file directory rooms should be failing, again. I'll have to get this sorted later. Fortunately, I still have the bare metal to compare against - unfortunately - I am not good at Linux permissions, or understanding Citadel and how to determine what account it is running under. 

Things about Citadel I don't understand that the documentation does not make very clear: 

https://citadel.org/system_administration_manual.html
States:

Creating a system account for Citadel

As with many Unix programs, Citadel wants to run under its own user ID. Unlike other programs, however, this user ID will do double-duty as a guest login if you are running a public system. This account is typically called "bbs" or "citadel" or something to that effect. You will tell Citadel what the user-id of that account is, and when someone logs in under that account, Citadel will prompt for a user name.

The Citadel user should have a unique uid. The home directory should be the one your Citadel installation resides in (in this example we will use /usr/local/citadel) and the shell should be either the citadel text-based client in that directory, or a script that will start up the citadel client. Example:

  citadel::100:1:Citadel Login:/usr/local/citadel:/usr/local/citadel/citadel

I'm not sure what this means, now. Does /usr/local/citadel/citadel run under a specific userID? Does /usr/local/webcit/webcit run under this userID too? Is this a service account, or a regular user account? This documentation is for compiling and installing your own instance of Citadel - do the same things apply when using Easy-Install? My understanding has always been that if there was a user named citadel or BBS that:

When you run setup later, you will be required to tell it the username or user ID of the account you created is, so it knows what user to run as. If you create an account called "citadel, bbs", or "guest", the setup program will automatically pick up the user ID by default.

The only user name that setup asks me for is the Sysop/Admin username and password. 

So - I made a *service account* called citadel on the VM before installing Citadel... 

and I've copied over the folders in /usr/local/citadel and /usr/local/webcit using rsync from my bare metal to the VM

I've noticed that I can no longer upload files. I get a permissions issue now in all of my file directory rooms. 

@secure:/usr/local/citadel$ ls -la

total 4600

drwxr-xr-x 10 citadel citadel    4096 May  5 08:31 .

drwx------  2 citadel root       4096 May  5 09:32 data

drwx------ 16 citadel root       4096 Apr 27 06:28 files

drwx------  6 citadel root       4096 Apr 27 06:28 keys

drwx------  2 citadel root       4096 Apr 27 06:28 messages

That folder is owned by the account "citadel" and the group is root, but there are no root permissions, if I'm reading the LS output correctly. I've yet to check this against the bare metal - but I suspect that even if the account "citadel" name matches the citadel account on the VM - there is a GUID error between those two accounts - so no account effectively has access to these directories. I can still access these folders as SU from a shell, though.  

Part of the problem that I've been having is that I am unable to get Webcit to redirect to the default wiki page I use as a welcome banner/bulletin, with a -g/dotgoto?room=hello modifier in webcit-http/https.service in /etc/systemd/system/

a ps aux returns: 
 

@secure:/usr/local/citadel# ps aux |grep webcit

root       313  0.0  0.2 193272 11760 ?        Ssl  08:31   0:00 /usr/local/webcit/webcit -p8916 -g/dotgoto?room=hello uds /usr/local/citadel

root       334  0.0  0.0  44608  1044 ?        Ss   08:31   0:00 /usr/local/webcit/webcit -D/var/run/webcit-ssl.pid -s -p443 uds /usr/local/citadel

root       336  0.0  0.6 1070720 30904 ?       Sl   08:31   0:03 /usr/local/webcit/webcit -D/var/run/webcit-ssl.pid -s -p443 uds /usr/local/citadel

root      8301  0.0  0.0   6208   888 pts/1    R+   11:49   0:00 grep webcit

Which to me looks like Citadel is running as the root UID, and that webcit-http.service is parsing correctly with the redirect modifier on port 8916

But webcit on SSL is launching with a modifier "-D/var/run/webcit-ssl.pid -s" on port 443. 

Which I can't find explained in any of the documentation. 

This is basically a placeholder documenting what I've encountered in troubleshooting what is going on, assuming at some point I'm going to have to reach out in the uncensored.citadel.org Citadel Support room - and I've gotten yelled at for having too much of a shotgun approach to these requests, in the past. 

blah blah blah

Smashbot might be able to help with this. He seems to be able to do some fairly complex programming type thingies. I'm basically useless in this regard. 

Well - the thing I am talking about - and that is why I grabbed the copy of ASGARD-86... is running a DOS machine running a traditional dial-up Citadel. I think visually - it would be clear that it was not the same as the webcit - although for the visually impaired - it would probably DESCRIBE almost identically to the text client - and that could be difficult. 

The thing is though - it would be a webcit only feature - so you would have to be hitting the Webcit to get into the DOS emulator running the dialup Cit. There wouldn't be a method to do that from a text-client session. 

Wed May 05 2021 21:59:15 MST from ASCII Express

Interesting idea bout running another Citadel just to run doors... though that could also confuse users.
I pondered whipping up a simple program to take a login, generate a dropfile, and run doors in a dos emulator. But then of course we'd want it to authenticate against Citadel, and then things get tricky. Maybe they will add doors code.

I couldn't help but to fuck with it some more. 

Tested on the test node with the test VM - and it worked... so I tried it on production after making another snapshot... and that worked, too. 

Permissions working - file directories working - Citadel starting right, on the right ports, and not launching multiple failing instances that fill the logs... and... and.... 

I've got the redirect before login to the "hello" wiki page working again for both HTTP and HTTPS.

I'm fucking stoked. Going to make another backup, another snapshot - and call this golden - then port this over to the test node too... 


This is the point of stability with Citadel I've been seeking. I've got 5 other exact hardware machines that can replace any hardware failure on the production machine - I've got multiple backup solutions, a test environment, a solid backup strategy - the security is working well... 

This thing is dialed in. NOW I'm going to leave it alone. :) 

The change did require some downtime and a reboot... 

Hopefully I didn't time that right when Jerry decided to connect again. :) 

But I'm looking forward to seeing MONTHS of uptime on the uptime counter on this server going forward. 

The BBS was running very slow - taking forever to render pages. Not sure what was going on - checked the bandwidth of my pipe and that seemed fine, and everything looked good in resources for the VM. I didn't see anything obvious in the VM that would be causing the issue. So I quickly rebooted the VM. That seemed to clear the issue. 

Maybe we were under a bit of a DDoS attack. I do get a LOT of people knocking on the door of the SSH server to see if I have root allowed. 

There are so many assholes in the world. 

Funny... I read your message about lagging response - and then opening this response took an extra long time. 

Sometimes I think it is the room itself - or the amount of content in the room. 

But anyhow - I guess the reason I thought of this is that I used to run Cits inside Cits in the old days. I couldn't tell you why now - but there were good reasons at the time. Running Cit-86, Asgard-86 and Novucivitas are probably where I learned to be innovative and think outside of the constraints of the code I was executing. Sometimes developers didn't add features, didn't know how to add features, or didn't want to add features - but you could bend or break their rules to achieve what they hadn't included. It was basically like running a VM at that time - you would run some variant of Citadel, it couldn't do something - but it could run ANOTHER Citadel of a different variety inside it, that then could do the thing you wanted. 

Which was a skill that paid off in my IT engineering career. I always approached things like, "Sure, they SAY their software can't do it... but their software can do THIS - and THAT can do it..."

Which is probably why I ended up on the black-ops IT team that took Intel from ~0% to 100% online eBiz between 2000 and 2003. Prior to 2000 - a lot of their supplier and other partner transactions were still taking place on paper - by the end, their entire supply to manufacturer line was digital and online.  

 

Wed May 12 2021 19:54:24 MST from ASCII Express

The thing is though - it would be a webcit only feature - so you
would have to be hitting the Webcit to get into the DOS emulator
running the dialup Cit. There wouldn't be a method to do that from a
text-client session. 

If you had it running then you could have telnet or an ssh account run the same emulator and serve it that way....right? maybe a virtual comport or FOSSIL thing?
It seems redundant to run two Citadels, but I get it. Maybe that would become the game room?
Honestly, I hate running software no longer in production. I chose Citadel in part for that reason.
But for running legacy doors we've crossed that line long ago!
Keep us posted with this. You may have something here.

I do think Fail2Ban is going to be it. It isn't the perfect solution - but at least it *tries* to fight back. 

Wed May 12 2021 19:55:42 MST from ASCII Express

Sometimes I notice some lag while typing in the text client. Yes I worry about bots attacking mine as well. Hopefully we can get some fail2ban support going.

The first automated backup of The Sanitarium to a remote Network Attached Storage device completed today, and will happen every Saturday going forward. 

This is a major step for us after being online for what - 2 years now? 

I don't think making a riot on Uncensored will move Ig if he doesn't want to do it or doesn't have the time. He isn't the kind of guy who is swayed by displays like that. He knows that we want it, that there is more than one person that sees value in it - if he gets the time and he thinks it can be done, he'll do it - but nothing more we can do will really change his mind at this point. 

I respect that about him. 

Part of the problem is he is in the middle of this major rewrite and they're a very small team driving code changes for this software - and there are absolutely a lot of things that are probably a WAY higher priority than adding door support. So - I think the best thing is to wait until the rewrite comes out and has a stable release on the new installer method - and then maybe bringing it up again, casually. :) Right now - I think it'll just piss him off and make him LESS likely to consider it. 

Sat May 15 2021 19:59:09 MST from ASCII Express

OK if we have to run a cit within a cit then cool. But we have to figure something out.
I checked in to the Saturday night net on the Blind Hams bridge. The net control (like the host of the round table) asked if anyone played text games, and several fondly remembered the BBS and expressed wanting to play those games again. I need to find a way to offer them. All the other BBS packages offer doors support.
Hmmm, what should we do? It appears that Citadel doesn't offer any way to run an external program now. Maybe we can keep making some gentle noise on Uncensored.

Or maybe figure something out.
So we'd have another Citadel like the game room?

Uncensored is a very unique Citadel culture - and basically ground zero for Citadel development at this point - at a time when most of the people who might contribute to its further development have long since lost their passion for the platform. 

I'd say what they need is more people in their development community contributing. 

I realized today I've been so busy and a little lazy and I haven't taken one of the automated backups and moved it from the production NAS to the internal NAS to restore it on the test Proxmox environment since I first set it up. I should do that. I need to do that, but I am totally procrastinating because I don't remember *exactly* how it was I copied from the one subnet to the other across the NAS devices. It wasn't *hard*... but I'm going to have to figure it out. 

I probably need to document that so I can refer to it when I *need* to do it. 

Well, figured out how to do it, again, and restored the production server backup from 6/5 to the test environment. Piece of cake - came right up, and it is *awesome*.