Here you can leave a comment for the site's owner regarding the site's content, appearance, functioning and, generally, write whatever you think on this. Please stay on topic (``on this'' doesn't mean ``on anything'') and respect the others.
Please note you can also contact the site's owner using the feedback page.
Please note that premoderation is in effect here.
☞ From Rol (unverified) Sun Oct 8 21:14:26 2023
Re: set up thalassa with Apache 2
Can you tell me what the file permissions on apache should be?
I have a testcms user whose home directory contains the "mysite" directory (a copy of the template).
In config.ini I specify "sitesrc=/home/testcms/mysite", "target=/var/www/html/mysite/data".
thalcgi.cgi and thalcgi.ini end up in the target directory by default.
How do I configure suexec to use testcms to throw files into target and thalcgi.ini was only available to the user from which thalcgi.cgi runs?
Or you can tell me how to organize this.
reply
Re: Re: set up thalassa with Apache 2
> How do I configure suexec to use testcms to throw files into target
Actually, I don't understand this question. Suexec does not throw any files anywhere.
Perhaps it is possible to create a kind of step-by-step instruction how to configure the apache+suexec+thalassa bundle, but it's definitely not for a small comment, it's a task for a day or so. As of now, may be I can provide some help if you tell what actually doesn't work, and how does that look.
reply
Re: Re: Re: set up thalassa with Apache 2
> Actually, I don't understand this question. Suexec does not throw any files anywhere.
Sorry, I meant running thalcgi gen from testcms to update files to /var/www/html/... or am I doing something wrong?
> if you tell what actually doesn't work, and how does that look
I tried installing thalassa locally on my computer. I was able to get the generated site to display and, apart from thalcgi.ini being accessible through the site, everything works fine.
After that I decided to figure out how to use suexec, but got caught up in file permissions.
I created a new "thalassa" user that I wanted to use in suexec. But it seems that the cgi owner and the directory in which it is located (/var/www/html/...) must be the same user.
But I thought that to own this directory should be www-data (user apache2). That’s why I never figured out how to give permission.
reply
Re: set up thalassa with Apache 2
> I meant running thalcgi gen from testcms to update files to /var/www/html/.
Well, this has nothing to do with suexec. Anyway, do I get it right that this (I mean, site generation to be done by thalassa) works for you and there's no problem with it?
> But it seems that the cgi owner and the directory in which it is located (/var/www/html/...) must be the same user.
It is intended to work this way, yes.
> But I thought that to own this directory should be www-data (user apache2).
This is true for a setup without suexec. Well, let me try to explain why we do need suexec, perhaps you don't fully understand it.
Actually, the web tree (these /var/www/html subtrees) may belong to any user, even to different users, the only important thing is to make all the content accessible to Apache, which is typically done making it world-readable, like with
chmod o+rX /var/www/html -R, which will set permissions for all files to smth. like 644 and directories like 755.For static content, this works perfectly, but it is problematic if you want to implement something server-side running programs, like CGI. Without suexec, Apache can only run anything under the same credentials it has itself. If your CGIs (or other server-side programs) only read something and never write, things are still more or less easy (just make everything readable to the same good uid which your Apache uses, and everything's fine), but once you need your programs to write something, you need to provide them with a place to do so, like directories writable for the apache user. In case of Thalassa, that session database directory must be made writable for the thalcgi.cgi.
From the other hand, you should never let all your static content AND the CGI binaries be writable for the Apache, as it is insecure. So, the site's administrator (that is, the person who is in charge for the content and for the server-side programs) from now on needs to have full access to TWO "users" of the system: the one which owns static content and the one which owns these CGI-writable dirs... which means the Apache user!
Well, if you ever tried to work with setups like this, you know it is terribly inconvenient unless you actually work as root, and this is exactly what people trying to run CGI without suexec typically end up with. Besides the fact that doing things like web content administering from under root is terrible from the security point of view, this might be just inappropriate in case you try with shared hosting, like if a single unix system (e.g., a VPS) serves two or more sites belonging to different users (that is, real persons who are different, heh). BTW, actually their CGIs can interfere because they will run under the same account, and even any of them can make bad things like killing the Apache :-) so that all other's sites will go down together.
Here's where suexec jumps in. The intention here is to have a designated site administrator account for every site on the machine, and to let the CGIs that belong to that site to run with the site administrator's credentials, not with the http server's creds. In your setup the "thalassa" user is perfectly suitable for that purpose. Even if there's only one site on the machine, using suexec is still convenient as everything you need (both the content and all these dirs your CGIs will write to) belongs to a single user, so you can either log in right under that user, or login as root and then do
su - thalassato become that user (well... not recommended, heh; root account should never be used when it is possible to avoid it).However, suexec is a SUID binary, and, like any SUID binary, it must always be assumed as an attractive target for various attacks. So it is written, well, paranoid enough. It performs a lot of security-related checks before actually running the CGI binary, and, among other things, neither the directory where the CGI resides, nor the CGI itself must be writable by someone else than the user configured as the site's user. So actually both the dir and the binary must belong to that user, because if they belong to someone else, that account will be able to rewrite the content of the binary, thus breaking into the site admin's account.
What I'd recommend is to make a subdir under your /var/www for each site-admin-user, in this case this can be /var/www/thalassa (well... leave that /var/www/html alone, for the "default" site, when the requested url doesn't match any of your virtual sites). There can be more than one of these accounts, e.g., if you decide to invite a friend to your server to host his/her site; add smth. like /var/www/johnny in that case. Let these dirs be owned by the respective accounts, e.g., do
Then, for each site to be served with Thalassa, make two directories, one for the site itself, and the other for its session database, like /var/www/thalassa/mysite and /var/www/thalassa/_mysite. And... well, and enjoy :-)
In your setup I'd recommend to create the third directory, like /var/www/thalassa/Mysite, for the site source (the place where to unpack Smoky to, that is, the place where these config.ini, thalassa.ini, base/ subdir and the company live). In case you want the thalassa account's home to be somewhere else, like traditionally in /home/thalassa, then make some symlinks pointing from there to /var/www/thalassa for convenience.
reply
Re: Re: set up thalassa with Apache 2
> the place where to unpack Smoky to, that is, the place where these config.cgi, thalassa.cgi, base/ subdir and the company live
*The suffixes must be . ini
> And... well, and enjoy :-)
I did everything you said. Now everything works as it should, thanks for the explanation!
reply
Re: Re: Re: set up thalassa with Apache 2
> The suffixes must be . ini
Sure, thank you. Fixed the text.
> Now everything works as it should
Congratulations :-)
reply
☞ From Not a user (unverified) Thu Sep 28 09:57:23 2023
small dependency (not that bad meaning) bug in the Makefile
If I compile with just make, everything is ok. But with make -j4 I get an error:
captcha.c:40:10: fatal error: _letters.c: No such file or directory 40 | #include "_letters.c" |Here is an example patch for it if you want to fix:
reply
Thanks!
Thank you for catching this. It's unlikely I'd ever manage to catch this flaw on my own because the whole thing with all the libs builds in less than 10 seconds so it's very unlikely I'd ever run make with
-j:-)The right fix here is different though. It is a single line
added anywhere in the Makefile, and yes, only the dep line without the command. Well, heh, the only reason it wasn't there already is that the lib/captcha directory is nearly the only one with a code written by someone else, not me. Oh, okay, md5 is also someone else's, but, well, it wasn't made for this project (unlike the captcha, which was intended for Thalassa).
reply
☞ From Ananas (unverified) Mon Sep 11 05:35:46 2023
Re: CGI settings
In order for the thalcgi.cgi to work, do I need to configure something else besides the config.ini. When trying to leave a comment on my site, for example, an error 404 is returned. Thanks!
reply
Re: CGI settings
The thalcgi.cgi program only uses one configuration file, named
thalcgi.ini(NOT config.ini, which I don't know where you got from).However, if you try thalcgi.cgi and get the 404, the problem is not with the config. In case thalcgi.cgi runs but fails to read its config file, it generates a built-in error page. So the problem is with your HTTP server configuration.
Try a script like this:
Place it in your site's directory, make sure you made it executable, and then hack your server's configuration until at the URL like http://your-site-domain-name.com/test.cgi you see the phrase "it works".
UPD: You didn't indicate it, but after some thoughts I suspect you're using the Smoky template, which really has a file named
config.ini. This may make the situation more complicated, because thalcgi.cgi has its own 404 page, which it displays in case the requested path (these path tokens afterthalcgi.cgi/) is either not configured, or the path predicate returnsnofor the respective page. So, it is necessary to have more information here, e.g., does thalcgi.cgi work properly for displaying the session status, the contact form and other things not related to comments.reply
Re: Re: CGI settings
1) Yes, I am using the Smoky template and I meant this particular config file. 2) Session status isn't displayed.The page with the suggestion to use cookies when necessary does not appear, contact form too. 3) I changed the server settings, now the scripts are running, but error 500 appears. I suspect that I have incorrectly configured access to some directories like thalcgi_db. I'll figure it out :)
reply
Re: Re: Re: CGI settings
> I suspect that I have incorrectly configured access to some directories like thalcgi_db
If thalcgi.cgi is able to run (that is, the server launches it upon the request), then no matter how wrong the environment is, it will show its own error message. What I'd check first is permissions set on the thalcgi.cgi and on the directory where it resides. And, okay, if it is able to run from its current location (some fascist sysadmins tend to set noexec everywhere, and it is simply stupid).
reply
Re: Re: Re: Re: CGI settings
After experimenting on the local machine, I found out that the problem was in the wrong server settings and the inability to read the thalcgi.ini by the thalcgi.cgi. It remains to figure out how to configure the suexec to prevent leaking of the thalcgi.ini. I should have read the documentation carefully first :)
reply
Re: Re: Re: Re: CGI settings
(In continuation of my comment today) Do I understand correctly that I need to activate the suexec in the Apache configuration, and set a SetUid for the thalcgi.cgi?
reply
Re: Re: Re: Re: Re: CGI settings
First of all, DO NOT set the SetUid bit!
As of suexec, I'm used to run sites with suexec, and that's what I strongly recommend, but it should still be possible to go without it. The
thalcgi.cgiprogram has an additional check for that situation.If you decide not to bother with suexec, then be sure to use your .htaccess file to prevent Apache from giving out the
thalcgi.inifile. Without suexec, CGIs run under the same UID as the HTTP server (Apache itself), so the ini file must be readable for that UID (and for the server), so additional step is needed to make sure it doesn't leak.reply
Re: CGI settings
It seems that I managed to set everything up correctly. Now it works :) I have a question: why does the thalassa always try to replace an existing .htaccess when generating content?
reply
Re: Re: CGI settings
It is told to generate its own .htaccess by the Smoky template's base files. Take a look at the
base/base.inifile, it contains the following section:[page .htaccess] body = +Options +FollowSymLinks +RewriteEngine on +RewriteCond %%{REQUEST_FILENAME} -d +RewriteRule ^(.*[^/])$ /$1/ [L] + +ErrorDocument 404 /404.html +This version does exactly three things: allows Apache to follow symbolic links (so that aliases can work, although Smoky by default doesn't use aliases), adds the trailing slash to directory URIs and sets the 404 page.
Is this problematic for you? If it is, perhaps I should think how to solve it in future versions of Smoky. As of now, you can simply comment out this section, the only downside of this is that you'll have to do it every time you update the base/ directory to a newer version.
reply
Re: Re: Re: CGI settings
> Is this problematic for you?
My .htacces looks different, so I don't need a replacement. I have this file owned by one user, and the thalassa is run on behalf of another, so the replacement fails. So my .htacces remains intact, so it's not a big problem for me.
reply
Re: CGI settings
It's generally not a good idea to rely on a program being unable to replace a file which it badly wants to replace but the replacement is not what the user needs. Actually, an error condition should never be considered a norm.
Well, I'll think what to do on this.
BTW, do I get it right you managed to run the Thalassa CGI in a non-suexec configuration? It's interesting for me as, honestly speaking, I never tried this.
reply
Re: CGI settings
> BTW, do I get it right you managed to run the Thalassa CGI in a non-suexec configuration?
Yes, I do. I have not activated the suexec module in Apache. The thalcgi.ini belongs to the server user and hiden with .htacces.
> It's generally not a good idea...
I agree, it's my bad. I wanted to launch a working website faster, and then slowly bring everything to mind, including the configuration of the server. I try different things, read your documentation and slowly everything falls into place. I want to create my own template later.
reply
Re: CGI settings
> I have not activated the suexec module
So it works. Great :-)
> The thalcgi.ini belongs to the server user
BTW, it doesn't have to belong to the server's uid, it only needs to be readable for the server's credentials (e.g., for the server's group).
> I wanted to launch a working website faster,
Understood, specially taking into account how immature both Thalassa and Smoky are. In the next version of Smoky I'll add an option to suppress generation of
.htaccess, and, perhaps, I'll also add filtering ofthalcgi.inifiles to the default version of it.> I want to create my own template later.
Oh, I really like this intention :-)
reply
☞ From Anonymous (unverified) Thu Aug 24 17:25:38 2023
Does not work on FreeBSD
g++ -Wall -g -c cmd.cpp -o cmd.o cmd.cpp: In function 'void safetcsetpgrp(int)': cmd.cpp:146:5: error: 'sighandler_t' was not declared in this scope; did you mean 'sigandset'? 146 | sighandler_t oldsig = signal(SIGTTOU, SIG_IGN); | ^~~~~~~~~~~~ | sigandset cmd.cpp:148:21: error: 'oldsig' was not declared in this scope 148 | signal(SIGTTOU, oldsig); | ^~~~~~ cmd.cpp: In constructor 'ExecResultParse::ExecResultParse(const char*, ...)': cmd.cpp:227:16: error: too few arguments to function 'int setpgrp(pid_t, pid_t)' 227 | setpgrp(); | ~~~~~~~^~ In file included from cmd.cpp:28: /usr/include/unistd.h:572:10: note: declared here 572 | int setpgrp(pid_t, pid_t); /* obsoleted by setpgid() */ | ^~~~~~~ cmd.cpp: In constructor 'ExecAndWait::ExecAndWait(const char*, ...)': cmd.cpp:265:16: error: too few arguments to function 'int setpgrp(pid_t, pid_t)' 265 | setpgrp(); | ~~~~~~~^~ /usr/include/unistd.h:572:10: note: declared here 572 | int setpgrp(pid_t, pid_t); /* obsoleted by setpgid() */ | ^~~~~~~ cmd.cpp: In constructor 'ExecAndWait::ExecAndWait(char* const*)': cmd.cpp:281:16: error: too few arguments to function 'int setpgrp(pid_t, pid_t)' 281 | setpgrp(); | ~~~~~~~^~ /usr/include/unistd.h:572:10: note: declared here 572 | int setpgrp(pid_t, pid_t); /* obsoleted by setpgid() */ | ^~~~~~~ cmd.cpp: In constructor 'ChrootExecWait::ChrootExecWait(const char*, const char*, ...)': cmd.cpp:313:16: error: too few arguments to function 'int setpgrp(pid_t, pid_t)' 313 | setpgrp(); | ~~~~~~~^~ /usr/include/unistd.h:572:10: note: declared here 572 | int setpgrp(pid_t, pid_t); /* obsoleted by setpgid() */ | ^~~~~~~ gmake[2]: *** [Makefile:39: cmd.o] Error 1 gmake[2]: Leaving directory '/root/thalassa-0.1.06/lib/scriptpp' gmake[1]: *** [Makefile:55: ../lib/scriptpp/libscriptpp.a] Error 2 gmake[1]: Leaving directory '/root/thalassa-0.1.06/cms' gmake: *** [Makefile:3: default] Error 2reply
Re: Does not work on FreeBSD
Thank you for reporting this. It is more or less obvious why it doesn't compile and how to fix the problem; however, unfortunately I've got no access to a working FreeBSD now, so I'll be unable to check if the result is okay.
Anyway, I'll do my best to fix this in the next source tarball to be published.
reply
Re: Does not work on FreeBSD
Also FreeBSD use clang and clang++ as default compillers. Please consider this feature.
reply
By the way...
:-)
reply
Re: By the way...
Errr... thanks :-)
reply
Re: Does not work on FreeBSD
Hello, i had same problem, but it is easy to repair. In file cmd.cpp just change all existing
signalhandler_ttosig_tandsetpgrp()tosetpgrp(0, 0)and all will be work fine. look on man signalreply
It's not THAT easy
If we do what you suggest, it won't compile under Linux and under some older unices.
sighandler_tis only used there to declare a single local variable, sovoid (*oldsig)(int);solves the problem. Well, no,sighandler_tcan NOT be anything else.As of
setpgrp(), it must be replaced withsetpgid(0, 0);, it is more or less portable. Furthermore,getpgid(0)should be used instead ofgetpgrp().reply
☞ From Anonymous (unverified) Sat Aug 19 20:47:22 2023
Interesting project!
This is a really fast html preprocessor! I want to try it next time for public information sites!
P.S. Logo image is too big.
reply
Re: Interesting project!
I myself was a bit surprised by how fast it works, specially taking into account that I didn't do any intentional optimizations for speed. However, surprisingly enough, it wasn't my goal to create another static HTML generator; for me it has any value only together with the CGI program which provides user comments feature.
Anyway, if you give Thalassa a try in one of your projects, any feedback is welcome.
As of the logo, you're right, I'll reduce it.
reply
☞ From Anonymous (unverified) Thu Jul 27 08:32:18 2023
Files suffixes
Why .html, not .xhtml for XHTML 1.0 Strict?
By default a lot of web servers response text/html for .html files, not application/xhtml+xml. So browser parse this as HTML page, not as XML.
reply
Re: Files suffixes
> XHTML 1.0 Strict?
It's not strict, it's "Transitional", solely because I need the iframe tag which is prohibited in the "Strict": in the head of the main page, that small black window with green chars is generated by the CGI, while all the page is static. Anyway, no part of generated content is hardcoded into the binaries, it all comes from the configuration, so it's possible to switch to the "Strict" version just by editing the ini files.
> Why .html, not .xhtml
The exact names of the files being generated are configured, too, so this is not a problem for Thalassa itself. Well, honestly speaking, in the present version of the Smoky template, the respective part of the configuration is within the ``base/'' subdirectory, which is not intended as user-editable, but nonetheless it can be edited. Actually, if this is important for you, I can add an option for the file extension in one of the upcoming versions.
However, as for the parser version: for the ``text/html'' mime type, as far as I understand the logic, the actual markup version is to be determined by the file's content, in which the exact format is specified, and I think this is generally better; furthermore, I doubt it is really correct to use ``application/*'' for anything intended as a human-readable text (to be rendered by the browser, not by an external application), despite servers, including the Apache I use, really emit that ``application/xhtml+xml'' for .xhtml files.
reply
☞ From Anon (unverified) Wed Jul 26 04:03:12 2023
Modules
Will there be support for modules/plugins without changing the core code?
reply
Re: Modules
Something like that is possible in future, but decisions of this sort should be balanced.
As of now, Thalassa consists of two statically-built binaries (the static content generator and the CGI), and the CGI even doesn't support loading multiple configuration files (the generator does, and in the Smoky template the configuration file for the CGI is actually composed by the generator). This minimalistic architecture has its own advantages, at least it is self-containing (hence minimal effort from the sysadmins) and quick.
Can you, maybe, give some examples of functionality you'd like to have implemented as modules?
As far as I can imagine, some useful things can be implemented simply as additional configuration sections, and some can be additional (optional) CGI programs, possibly using the same session data (the cookie and all related stuff) and user accounts; such CGIs can be thought of as plugins. Should we ever need more built-in macros in the generator, it is better to implement them within the existing program, may be as optional modules added at the compile time.
What I'd like to avoid is an infrastructure for real pluggable modules.
reply
☞ From Nokia user (unverified) Tue Jul 25 11:56:47 2023
What about WAP version support?
What do you think about add generation WML versions of sites?
reply
Re: What about WAP version support?
There's no need to add anything like that to Thalassa itself, because actually Thalassa is a (domain-specific) macroprocessor, so it is able to generate whatever texts you want. For example, there's RSS feed on this site, despite there's no special support for RSS in Thalassa, it is solely a question of writing proper configuration files.
As of adding WAP, e.g., to the Smoky template, it might be a good idea, but personally I'm not familiar with WAP and right now I've got higher-priority tasks. Maybe later.
reply