Admin UI & Search Feature not for Two Instances

[micadeyeye]

Hi,
I am doing more test on your great piece of work.

For two instances on the same host, we noticed that the (admin) editor UI is only available on logging in to .../edit/.... URL pattern for the first instance. It throws an error - service not available - for the second instance. The two are sharing the ContentEditor_password file as you aware that no changes are made to it when setting up the second instance.

We still can't get the search feature to work too as previously mentioned. It throws a server error - service not available. We tried tracing it back then via log etc but couldn't get useful information.

Lastly, having tweaked a few files - css, articles html files, etc, would upgrading & rebuilding the package reset the files?

[cyclaero]

Are you talking about two virtual hosts, i.e. 2 sites served by the same Apache web server? If yes, did you see my instructions on the FreeBSD forums?
https://forums.freebsd.org/threads/contenttools-and-contentcgi.66375/#post-450224

The important part is, that you need to launch 2 instances of ContentCGI, and one of which got a different name. That means you need to edit a copy of the ContentCGI's rc file as shown in said post and then launch it in addition to the first instance. In the second virtual host configuration, you would point the directive ProxyPass to the second ContentCGI daemon. I guess, this would resolve the login issue.

Regarding the search problem, please inform the location of the search index on your system. As I mentioned in another post on the FreeBSD Forums, the location was changed in the past, and perhaps, your setup still refers to the old location.
https://forums.freebsd.org/threads/contenttools-and-contentcgi.66375/#post-446384

Files which are placed into the webdocs directory, i.e. the files which Apache would server on request, would not be touched by simply updating ContentCGI. But, you must not execute the script plugins/content-delegate/generate-webdocs.sh as part of the update, since this is meant only for bootstrapping an otherwise empty site.

However, it would not harm to backup the webdocs from time to time, principally when you are going to apply major changes to the system.

[micadeyeye]

Thanks for the URLs.

In the second virtual host configuration, you would point the directive ProxyPass to the second ContentCGI daemon. I guess, this would resolve the login issue.

All of these steps were followed. Otherwise, the contents of the two instances would have cross-referenced each other as we found out.

I reckon the problem with the search is linked to Apache. I can't think of how else to point nail it down to a particular cause - lib versions, conf, etc.

And for the upgrade, your recommendation is noted.

Thanks.

[cyclaero]

Please send the virtual host files of the respective sites (you may obfuscate the site's domain names). Also I would like to see the cloned rc-file of the second ContentCGI instance. Alternatively send links to it, e.g. pastebin.

The search problem is most probably an issue with a displaced directory of the search index.

I am very bad in telling fortunes. Please let me analyse the facts, and then we may resolve the issues. I operate three servers each running multiple sites in different domains by the way of Apache's virtual hosts configuration. Everything, including searching is running smooth and without any hick-ups.

[micadeyeye]

I can confirm that SecondCGI.sock and SecondCGI.pid do not exist yet the second site loads. All hacks to bring them up fail.

[cyclaero]

Do the following as user root:

1. sed -e "s|ContentCGI|SecondCGI|g;s|-w /usr/local/www/SecondCGI/webdocs|-l 0 -s 0 -u www:www -d /tmp/SecondCGI.sock -p /var/run/SecondCGI.pid -w /usr/local/www/SecondCGI/webdocs|" /usr/local/etc/rc.d/ContentCGI > /usr/local/etc/rc.d/SecondCGI
    

2. chmod +x /usr/local/etc/rc.d/SecondCGI
    

3. ln -s ContentCGI /usr/local/bin/SecondCGI
    

4. service SecondCGI onestart
    

5. ls -l /tmp/*.sock

   srw-rw-rw- 1 root wheel 0 May 1 23:19 /tmp/ContentCGI.sock
   srw-rw-rw- 1 root wheel 0 May 2 11:01 /tmp/SecondCGI.sock

Once you see the socket file /tmp/SecondCGI.sock, add the start directive SecondCGI_enable="YES" to the file /etc/rc.conf`.

[micadeyeye]

Most of these commands had been run in the past save the sed's. Unfortunately, on trying them again, the SecondCGI sock and pid files were not created.

The only notification that can help further trace the problem can be found in the messages log.

Here is it:

2020-05-03T02:09:49.734720+00:00 HOSTNAME SecondCGI[57878] The daemon could not lock its pid file - 35

[cyclaero]

I revised the sed command. Please try it again. The rc script must be made executable as well, therefore please do not forget to execute step 2.

[micadeyeye]

No luck.

[cyclaero]

No luck what? Do you still see the following?

2020-05-03T02:09:49.734720+00:00 HOSTNAME SecondCGI[57878] The daemon could not lock its pid file - 35

In case yes, you want to repeat the exact sed-command as I have written above, here in this issue thread. I mean neither that of the FreeBSD thread nor that in the history of your shell.

In case this turns out to be too difficult, add the following directive to the file /etc/rc.conf right before enabling SecondCGI:

SecondCGI_flags="-p /var/run/SecondCGI.pid"

In case it is no more the PID issue, do you see another notification in /var/log/messages?

[micadeyeye]

ContentCGI makes a socket connection at HostIP:4000 when 'sockstat -4l' lists all port connections. SecondCGI isn't listed. I presume it could not run at the same port. I tried checking where 4000 was specified. It seems it's hardcoded into the src. You reckon we need 'make install' again after changing the port no for SecondCGI?

[cyclaero]

The options -l 0, -s 0 prevent SecondCGI from open TCP sockets, and therefore it won't be in conflict with ContentCGI. SecondCGI will only operate via the UNIX domain socket at /tmp/SecondCGI.sock

see:
sed -e "s|ContentCGI|SecondCGI|g;s|-w /usr/local/www/SecondCGI/webdocs|-l 0 -s 0 -u www:www -d /tmp/SecondCGI.sock -p /var/run/SecondCGI.pid -w /usr/local/www/SecondCGI/webdocs|" /usr/local/etc/rc.d/ContentCGI > /usr/local/etc/rc.d/SecondCGI
chmod +x /usr/local/etc/rc.d/SecondCGI

[micadeyeye]

No difference. SecondCGI.sock & SecondCGI.pid not created.

[cyclaero]

Do you work with the latest ContentCGI, if no, when was the last update?

On the command line enter as user root: service SecondCGI start
Then report the notification in /var/log/messages on why SecondCGI where stopped, i.e. one of:

1. Error creating the Unix domain socket.
2. Error calling bind() on the Unix domain socket: -xx.
3. The access rigths of the Unix domain socket could no be set: -xx.
4. Error calling listen() on the Unix domain socket.

In case you are working with an old version, -l 0 and -s 0 would not be effective, and you may see errors about establishing TCP listening sockets at some stage.

In case you don't want to update, redo the sed command using other TCP port numbers:
sed -e "s|ContentCGI|SecondCGI|g;s|-w /usr/local/www/SecondCGI/webdocs|-l 4001 -s 5001 -u www:www -d /tmp/SecondCGI.sock -p /var/run/SecondCGI.pid -w /usr/local/www/SecondCGI/webdocs|" /usr/local/etc/rc.d/ContentCGI > /usr/local/etc/rc.d/SecondCGI chmod +x /usr/local/etc/rc.d/SecondCGI

[micadeyeye]

This command - sed -e "s|ContentCGI|SecondCGI|g;s|-w /usr/local/www/SecondCGI/webdocs|-l 4000 -s 4001 -u www:www -d /tmp/SecondCGI.sock -p /var/run/SecondCGI.pid -w /usr/local/www/SecondCGI/webdocs|" /usr/local/etc/rc.d/ContentCGI > /usr/local/etc/rc.d/SecondCGI

• got SecondCGI.pid up. However SecondCGI.sock is not in the tmp dir. The editor link still throws 'Service Unavailable'.

[cyclaero]

Please update to the latest version. The point is, that your old version does not allow specifying the socket path by the way of the -d option. You need to update.

[micadeyeye]

That was easy.
./bsdinstall.sh update install clean
At revision 86.
Updating '.':
UU README.md
UU build/content-tools.js
UU build/content-tools.min.css
UU build/content-tools.min.js
UU external/scripts/content-edit.js
A package-lock.json
UU package.json
UU sandbox/sandbox.css
UU sandbox/sandbox.js
UU src/sandbox/sandbox.coffee
UU src/scripts/clean-html.coffee
UU src/scripts/editor.coffee
UU src/styles/_settings.scss
A translations/ca.json
Updated to revision 460.
Updating '.':
UU ContentCGI.xcodeproj/project.pbxproj
UU plugins/content-delegate/Makefile
UU plugins/content-delegate/content-delegate.js
UU plugins/content-delegate/models/styles.css
Updated to revision 239.
......
.......

It won't help. Hopefully, we will soon get more users showing interest in this cool project.

[cyclaero]

You wrote "It won't help." Can you be more specific please?

[micadeyeye]

After the update, I tried this - #1 (comment).

I can see "/usr/local/bin/ContentCGI -u www:www -w /usr/local/www/ContentCGI/webdocs" in ps aux. Nothing happens when the 'ContentCGI' in the command is changed to SecondCGI and executed.

I can see that 'service SecondCGI (re)start' kills the ContentCGI.sock though ContetCGI is still shown in 'ps aux' as running.

[cyclaero]

service SecondCGI restart must not touch ContentCGI.sock. For this reason it got -d /tmp/SecondCGI.sockon the command line. Does the web directory exist? /usr/local/www/SecondCGI/webdocs
Anything in /var/log/messages?

[micadeyeye]

Definitely!

[cyclaero]

I just repeated all this: #1 (comment)

Here ps -axj shows:

www       1135     1  1135  1135    0 Is    -     0:00.20 /usr/local/bin/ContentCGI -l 0 -s 0 -u www:www -w /usr/local/www/Obsigna/webdocs
www      36617     1 36617 36617    0 Is    -     0:00.07 /usr/local/bin/SecondCGI -l 0 -s 0 -u www:www -d /tmp/SecondCGI.sock -p /var/run/SecondCGI.pid -w /usr/local/www/SecondCGI/webdocs (ContentCGI)

Definitely something went wrong with your setup.