search

cyclaero / ContentCGI

Extensible FastCGI Daemon for FreeBSD
BSD 2-Clause "Simplified" License
2 stars 0 forks source link

Admin UI & Search Feature not for Two Instances #1

Open micadeyeye opened 4 years ago

micadeyeye commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

No luck.

cyclaero commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

cyclaero commented 4 years ago

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 commented 4 years ago

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

cyclaero commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

micadeyeye commented 4 years ago

After the update, I tried this - https://github.com/cyclaero/ContentCGI/issues/1#issuecomment-623533094.

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 commented 4 years ago

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 commented 4 years ago

Definitely!

cyclaero commented 4 years ago

I just repeated all this: https://github.com/cyclaero/ContentCGI/issues/1#issuecomment-622958919

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.