Language:
switch to room list switch to menu My folders
Go to page: 1 3 4 5 6 [7]
[#] Tue May 04 2021 21:02:17 MST from ParanoidDelusions <paranoiddelusions@wallofhate.com>

[Reply] [ReplyQuoted] [Headers] [Print]

Just testing... 

 



[#] Wed May 05 2021 09:43:44 MST from ParanoidDelusions <paranoiddelusions@wallofhate.com>

[Reply] [ReplyQuoted] [Headers] [Print]

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. 

 

 



[#] Wed May 05 2021 11:56:39 MST from ParanoidDelusions <paranoiddelusions@wallofhate.com>

[Reply] [ReplyQuoted] [Headers] [Print]

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



[#] Wed May 05 2021 21:36:51 MST from ASCII Express

[Reply] [ReplyQuoted] [Headers] [Print]

I have a citadel account for running citserver. I also pass that option to webcit, but for some reason it still runs as root. I don't have it as a system account, but perhaps I should.
I then have a separate bbs account for users to log in. I figure better safe than sorry. That runs /usr/local/citadel/citadel as a shell. So far I haven't had any permissions issues. *knocks on wood*

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

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Thu May 06 2021 07:16:09 MST from ParanoidDelusions <paranoiddelusions@wallofhate.com>

[Reply] [ReplyQuoted] [Headers] [Print]

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.

 



[#] Thu May 06 2021 15:53:41 MST from ParanoidDelusions <paranoiddelusions@wallofhate.com>

[Reply] [ReplyQuoted] [Headers] [Print]

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. :) 

 



[#] Thu May 06 2021 15:54:43 MST from ParanoidDelusions <paranoiddelusions@wallofhate.com>

[Reply] [ReplyQuoted] [Headers] [Print]

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. 



[#] Mon May 10 2021 17:49:36 MST from ParanoidDelusions <paranoiddelusions@wallofhate.com>

[Reply] [ReplyQuoted] [Headers] [Print]

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. 

 

 

 



Go to page: 1 3 4 5 6 [7]