not@telling.you.invalid (Computer Nerd Kev) writes:

> Meredith Montgomery <mmontgomery@levado.to> wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>
>> [...]
>>
>>>> (*) My thought process leading up to this
>>>>
>>>> Solution 1. Students could send me e-mails, but I have the massive work
>>>> of pulling files from my inbox into a UNIX system where I can look at
>>>> each one. E-mail does the job because it /sort of/ proves the
>>>> delivery.
>>>
>>> This is what I used to do. The email had to have the exercise number in
>>> the subject. I used to use mh, so a simple script could find
>>> coursework, extract the work and, if appropriate, compile and run tests
>>> on it.
>>>
>>> I wonder why getting mail onto a Unix system would be such hard work.
>>> What's going on to make that the case?
>>
>> I can't run a MTA in this server because e-mail ports are blocked by the
>> ISP. I can pay more and get that out of the way, though.
>>
>> But it seems you mean you had a script that would look into an inbox and
>> extract homework from messages. But my mail is not in the UNIX system.
>> I'd need a script to POP3-download or IMAP-download or something like
>> that. I wouldn't know how to quickly do something like that.
>
> It shouldn't be hard with Movemail from GNU Mailutils, or
> alternatives like fdm:
> https://www.mailutils.org/wiki/Fetching_Mail_with_Movemail

Thanks for pointers.

[...]

>> E-mail has the downside that the mechanism doesn't report right away
>> that the student is using it wrong. A run of scp (if there's no way for
>> files to the wrong directory) would always be successful (as long as I
>> could name the files).
>
> Well email sent should always end up in your mailbox (though
> using Gmail puts this logic at risk because they like to reject
> things that they falsely identify as malicious), so it seems the
> same to me. With email you don't have to set up a separate user on
> the system for each student in order to identify who uploaded what.

You got a point. E-mail has the problem that people say --- I sent it
---, but we never got it. In the end it really seems that the HTTP
server is the easiest to use and the most straightforward alternative.
It sucks that I have to write it, but I can probably get this done in a
weekend, not including the Javascript drag-and-drop, which I'd have to
learn about.

Bob Eager <news0009@eager.cx> writes:

> On Sun, 04 Sep 2022 17:22:37 -0300, Meredith Montgomery wrote:
>
>> Nevertheless, this gives me the idea that if I write a web server for
>> the job, we should have an endpoint that students can submit their work
>> through the command-line. (A nice interface for the more technical
>> people.)
>
> Have you looked at installing Moodle?

I've used it before as a student. It's a whole system for such stuff.
I did not like to use it as a student --- it seemed ugly visually
speaking.

On Sun, 04 Sep 2022 21:39:34 -0300, Meredith Montgomery wrote:

> Bob Eager <news0009@eager.cx> writes:
>
>> On Sun, 04 Sep 2022 17:22:37 -0300, Meredith Montgomery wrote:
>>
>>> Nevertheless, this gives me the idea that if I write a web server for
>>> the job, we should have an endpoint that students can submit their
>>> work through the command-line. (A nice interface for the more
>>> technical people.)
>>
>> Have you looked at installing Moodle?
>
> I've used it before as a student. It's a whole system for such stuff.
> I did not like to use it as a student --- it seemed ugly visually
> speaking.

It is customisable.

And in any case, it's the functionality that matters.

As an academic, I found it very good.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

Bob Eager <news0009@eager.cx> writes:

> On Sun, 04 Sep 2022 21:39:34 -0300, Meredith Montgomery wrote:
>
>> Bob Eager <news0009@eager.cx> writes:
>>
>>> On Sun, 04 Sep 2022 17:22:37 -0300, Meredith Montgomery wrote:
>>>
>>>> Nevertheless, this gives me the idea that if I write a web server for
>>>> the job, we should have an endpoint that students can submit their
>>>> work through the command-line. (A nice interface for the more
>>>> technical people.)
>>>
>>> Have you looked at installing Moodle?
>>
>> I've used it before as a student. It's a whole system for such stuff.
>> I did not like to use it as a student --- it seemed ugly visually
>> speaking.
>
> It is customisable.
>
> And in any case, it's the functionality that matters.
>
> As an academic, I found it very good.

Looking at it at

https://moodle.org/

right now. It's looking very good, actually. Very different from I saw
a few years ago at my university. I'm considering that. Thank you for
the reminder! I would not think of it at all.

On Sun, 04 Sep 2022 17:09:28 -0300, Meredith Montgomery
<mmontgomery@levado.to> wrote:

> This idea seems very interesting. I think you're saying each student
> would have their own repository and they would push their repository to
> a server (from where I'd pull and look at).

If you want to explore the repository solution, you may be
interested in fossil, https://www.fossil-scm.org/

(its architect is the creator of the SQLite database engine)
--
Regars,
Kees Nuyt

On 01/09/2022 02:07, Meredith Montgomery wrote:
> I'm thiking about creating UNIX accounts merely for students to upload
> their homework through scp. But I have not solved all what I want to
> solve. (Such students are expected to be technical enough to use scp.)
>

Git (and no, not GitHub)

--
Adrian C

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Wed, 31 Aug 2022 22:07:17 -0300, Meredith Montgomery wrote:
>
>> I'm thiking about creating UNIX accounts merely for students to upload
>> their homework through scp. But I have not solved all what I want to
>> solve. (Such students are expected to be technical enough to use scp.)

[...]

> As an alternative, you could look into one of the many "revision control"
> systems. I'm thinking specifically of git or cvs, both of which can handle
> networked commits.
>
> In theory, your students would "commit" their homework to your repository,
> and you could then "pull" the homework out to be evaluated. Such revision
> control systems include user privilege management that you may be able
> to use to limit a student's ability to, for instance, "commit" to another
> student's homework, or "pull" another student's homework for copying.
>
> It would take a bit of set-up, but would give you control over what the
> students can access, and an audit trail of what they /have/ accessed.

That really helped! Kees Nuyt in

<hh6ehh1l21v56f7b66nc7llm2q88oii3ob@dim53.demon.nl>

ended up mentioning [fossil](https://www.fossil-scm.org/), which
captivated me with its very straightforward user interface for managing
the server-side of things. Its password management, for example, is
very straightforward, so I quickly committed myself to it because you
feel you can handle it if things ever break, say.

Now I'm learning to use it. Your idea is to set up a separate
repository for each student and give access to it only to that student
(and myself). I can put the homework in the repository, the student
will clone that, read the assignment, do it and sync it back. I will
then fetch the changes when grading and I provide feedback on the
repository itself --- including sending the student's grade back. That
will work and I like that.

Thank you so very much! (To you and to Kees Nuyt!)

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:

> On Sun, 04 Sep 2022 17:09:28 -0300, Meredith Montgomery
> <mmontgomery@levado.to> wrote:
>
>> This idea seems very interesting. I think you're saying each student
>> would have their own repository and they would push their repository to
>> a server (from where I'd pull and look at).
>
> If you want to explore the repository solution, you may be
> interested in fossil, https://www.fossil-scm.org/
>
> (its architect is the creator of the SQLite database engine)

Thank you so very much. The software captivated me. Now I'm learning
how to use it. My first thought was to make a repository for each
student and give them clone, password, check-in and check-out
permissions (I suppose that's what I need).

Would I have to put up a web server for each student? I guess so! They
must be able to clone it, after all. Perhaps you guys are thinking of a
single repository with permissions on a branch basis, so I create a
branch for each student? I don't know. Probably, right? Running so
many servers would be nightmare.

I'd have to learn how to set permission on a branch basis or something
like that. I don't know. I gotta learn how to do this.

On Tue, 06 Sep 2022 22:32:27 -0300, Meredith Montgomery
<mmontgomery@levado.to> wrote:

> Thank you so very much. The software captivated me.

My pleasure.

> Now I'm learning
> how to use it. My first thought was to make a repository for each
> student and give them clone, password, check-in and check-out
> permissions (I suppose that's what I need).

That will work.

> Would I have to put up a web server for each student? I guess so! They
> must be able to clone it, after all.

> Perhaps you guys are thinking of a
> single repository with permissions on a branch basis, so I create a
> branch for each student? I don't know. Probably, right?

In fossil, permissions are given for the whole repository, there
are no per-branch permissions.

> Running so
> many servers would be nightmare.

That would be a nightmare indeed. Luckily it is not needed. One
webserver will do. Fossil can run as CGI, with one simple CGI
script per repository.

For example, I run about 35 fossil repostories behind one
lighttpd web server. Each repository can be accessed with:

https://sub.domain.tld/fossil/REPONAME

Directory structure:

/var
+-fossil
+-cgi
+-repo

The repo directory contains a file for each repository,
with the name REPONAME.fossil.
Note: the /var/fossil/repo and the .fossil files in it must be
writable by the webserver user (www-data)

The cgi directory contains a CGI script for each repository,
/var/fossil/cgi/REPONAME, mode -r-xr-x---
user:group: www-data:www-data
containing just:

#!/usr/local/bin/fossil
repository: /var/fossil/repo/REPONAME.fossil

Lighttpd configuration snippet:
# ## CGI for fossil reposiitories
# $HTTP["url"] =~ "^/fossil" {
alias.url += ( "/fossil/" => "/var/fossil/cgi/" )
cgi.assign = ( "" => "" )
}

> I'd have to learn how to set permission on a branch basis or something
> like that. I don't know. I gotta learn how to do this.

You can script the creation of the per-student repository and
the cgi scripts.
The student should get developer permissions for his/her repo on
the server.

You create the repos on your server,
The students clone their own repo to their own machine and open
a checkouyt.
They automatically have all permissions on that local clone.

They checkin their work to the local repo and sync that with
their repo on the server.
You can checkout on the server to a per student directory, or
extract files directly from the repo.

docs: the fossil-scm website and :
fossil help user
fossil help new
fossil help clone
fossil help settings
fossil help cat

https://www.fossil-scm.org/home/doc/trunk/www/server/
https://www.fossil-scm.org/home/doc/trunk/www/server/any/cgi.md

Community:
https://fossil-scm.org/forum/forum

--
Good luck,
Kees Nuyt

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:

> On Tue, 06 Sep 2022 22:32:27 -0300, Meredith Montgomery

[...]

>> Would I have to put up a web server for each student? I guess so! They
>> must be able to clone it, after all.
>
>> Perhaps you guys are thinking of a
>> single repository with permissions on a branch basis, so I create a
>> branch for each student? I don't know. Probably, right?
>
> In fossil, permissions are given for the whole repository, there
> are no per-branch permissions.

Thanks!

>> Running so many servers would be [a] nightmare.
>
> That would be a nightmare indeed. Luckily it is not needed. One
> webserver will do. Fossil can run as CGI, with one simple CGI
> script per repository.

I'm running nginx. So I'm gonna have to learn how to run at least one
CGI and I'm having a hard time understanding the problem here. I'm
running OpenBSD 7.

%uname -a
OpenBSD my.host.name 7.0 GENERIC.MP#232 amd64
%

My revelant nginx.conf is essentially this:

--8<---------------cut here---------------start------------->8---
http {
# [...]

server {
listen 80;
server_name my.host.name;
location /cgi/ {
gzip off;
root /students/cgi;
fastcgi_pass unix:/students/cgi.socket;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME /students/cgi$fastcgi_script_name;
}
}
} --8<---------------cut here---------------end--------------->8---

I wrote

%cat /students/cgi/test.cgi
#!/bin/sh
echo "Content-type: text/plain"
echo
echo "Today is $(date). Thank you for coming."
%

%pwd
/students

%ls -lR .
..:
total 8
drwxr-xr-x 2 www wheel 512 Sep 7 15:41 cgi
prw------- 1 www wheel 0 Sep 7 15:21 cgi.socket

../cgi:
total 8
-rwxr-xr-x 1 www wheel 94 Sep 7 15:41 test.cgi
%

When my browser hits

http://my.hostname/cgi/test.cgi

I get 502 bad gateway on the web and I see in the logs --- breaking long
lines into at most 72 columns. (I hope that's useful.)

--8<---------------cut here---------------start------------->8---
2022/09/07 15:24:56 [crit] 48490#0: *42 connect() to
unix:/students/cgi.socket failed (38: Socket operation on non-socket)
while connecting to upstream, client: 1.2.3.4, server: my.host.name,
request: "GET /cgi/test.cgi HTTP/1.1", upstream:
"fastcgi://unix:/students/cgi.socket:", host: "my.host.name" 2022/09/07

15:24:56 [crit] 48490#0: *42 connect() to unix:/students/cgi.socket
failed (38: Socket operation on non-socket) while connecting to
upstream, client: 1.2.3.4, server: my.host.name, request: "GET
/cgi/test.cgi HTTP/1.1", upstream:
"fastcgi://unix:/students/cgi.socket:", host: "my.host.name" 2022/09/07

15:24:56 [crit] 48490#0: *42 connect() to unix:/students/cgi.socket
failed (38: Socket operation on non-socket) while connecting to
upstream, client: 1.2.3.4, server: my.host.name, request: "GET
/cgi/test.cgi HTTP/1.1", upstream:
"fastcgi://unix:/students/cgi.socket:", host: "my.host.name"
--8<---------------cut here---------------end--------------->8---

I'm changing my real IP address up there and my real hostname.

Looking at errno(2), I see

--8<---------------cut here---------------start------------->8---
38 ENOTSOCK Socket operation on non-socket. Self-explanatory.
--8<---------------cut here---------------end--------------->8---

I'm puzzled. It seems nginx is trying to call connect() on the UNIX
domain socket, which I guess is possible, but I would have expected a
simple open() on the named pipe.

If I don't create the named pipe, nginx reports ``no such file or
directory''. When I create it, I get the above. I created it with
``mkfifo cgi.socket''. (Then changed owner, changed permissions.)

The documentation at

https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

says I'm doing the right thing:

``fastcgi_pass unix:/tmp/fastcgi.socket;''

So I'm stuck there.

I'll follow your approach with the repositories. Thank you!

I'll run lighthttpd if I have to.

> For example, I run about 35 fossil repostories behind one
> lighttpd web server. Each repository can be accessed with:
>
> https://sub.domain.tld/fossil/REPONAME
>
> Directory structure:
>
> /var
> +-fossil
> +-cgi
> +-repo
>
>
> The repo directory contains a file for each repository,
> with the name REPONAME.fossil.
> Note: the /var/fossil/repo and the .fossil files in it must be
> writable by the webserver user (www-data)
>
> The cgi directory contains a CGI script for each repository,
> /var/fossil/cgi/REPONAME, mode -r-xr-x---
> user:group: www-data:www-data
> containing just:
>
> #!/usr/local/bin/fossil
> repository: /var/fossil/repo/REPONAME.fossil
>
> Lighttpd configuration snippet:
> #
> ## CGI for fossil reposiitories
> #
> $HTTP["url"] =~ "^/fossil" {
> alias.url += ( "/fossil/" => "/var/fossil/cgi/" )
> cgi.assign = ( "" => "" )
> }
>
>
>> I'd have to learn how to set permission on a branch basis or something
>> like that. I don't know. I gotta learn how to do this.
>
> You can script the creation of the per-student repository and
> the cgi scripts.
> The student should get developer permissions for his/her repo on
> the server.
>
> You create the repos on your server,
> The students clone their own repo to their own machine and open
> a checkouyt.

You have a typo here. The letters yt are neighors in an american
keyboard. But yt is also present in your name. So maybe that's why you
had this typo here. We have two possibilities here and it doesn't seem
easy to tell which is the right one.

``We must know. We will know.'' -- David Hilbert

> They automatically have all permissions on that local clone.
>
> They checkin their work to the local repo and sync that with
> their repo on the server.
> You can checkout on the server to a per student directory, or
> extract files directly from the repo.
>
> docs: the fossil-scm website and :
> fossil help user
> fossil help new
> fossil help clone
> fossil help settings
> fossil help cat
>
> https://www.fossil-scm.org/home/doc/trunk/www/server/
> https://www.fossil-scm.org/home/doc/trunk/www/server/any/cgi.md
>
> Community:
> https://fossil-scm.org/forum/forum

On Wed, 07 Sep 2022 16:03:09 -0300, Meredith Montgomery
<mmontgomery@levado.to> wrote:

[...]

> I'm running nginx. So I'm gonna have to learn how to run at least one
> CGI and I'm having a hard time understanding the problem here. I'm
> running OpenBSD 7.

I think you are stuck because you tried a mix of fastcgi and
plain cgi.
The simple CGI script I showed will not work for FastCGI or
SCGI.

Not running nginx myself I can only refer to this matrix :
https://www.fossil-scm.org/home/doc/trunk/www/server/#matrix

[...]
> I'll run lighthttpd if I have to.

For small scale sites lighttpd is pretty good.
Another, even lighter alternative is althttpd.
https://sqlite.org/althttpd/
(A single C-source you can compile yourself)

[...]

> > The students clone their own repo to their own machine and open
> > a checkouyt.
>
> You have a typo here. The letters yt are neighors in an american
> keyboard. But yt is also present in your name.

Yeah, I often fat-finger t and y and u and y :D
Here, I meant to type checkout.

--
Regards,
Kees Nuyt

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:

> On Wed, 07 Sep 2022 16:03:09 -0300, Meredith Montgomery
> <mmontgomery@levado.to> wrote:
>
> [...]
>
>> I'm running nginx. So I'm gonna have to learn how to run at least one
>> CGI and I'm having a hard time understanding the problem here. I'm
>> running OpenBSD 7.
>
> I think you are stuck because you tried a mix of fastcgi and plain
> cgi. The simple CGI script I showed will not work for FastCGI or
> SCGI.

I got puzzled there, but I'll let that one go and try your next
suggestions.

> Not running nginx myself I can only refer to this matrix :
> https://www.fossil-scm.org/home/doc/trunk/www/server/#matrix
>
> [...]
>
>> I'll run lighthttpd if I have to.
>
> For small scale sites lighttpd is pretty good.
> Another, even lighter alternative is althttpd.
> https://sqlite.org/althttpd/
> (A single C-source you can compile yourself)

Sounds good. But I would not like to replace nginx completely because
it answers many other hostnames. I'm thinking I can use nginx as a
proxy to althttpd --- just so I don't have to ask users to memorize port
numbers in their web addresses. I'll try that. (I like the
single-source I can compile myself.)

> [...]
>
>> > The students clone their own repo to their own machine and open
>> > a checkouyt.
>>
>> You have a typo here. The letters yt are neighors in an american
>> keyboard. But yt is also present in your name.
>
> Yeah, I often fat-finger t and y and u and y :D
> Here, I meant to type checkout.

I'm glad you got a sense of humor. :D

Thank you!

I'll write again. (More later!)

Meredith Montgomery <mmontgomery@levado.to> wrote:
> Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>
>> On Wed, 07 Sep 2022 16:03:09 -0300, Meredith Montgomery
>> <mmontgomery@levado.to> wrote:
>>
>> [...]
>>
>>> I'm running nginx. So I'm gonna have to learn how to run at least one
>>> CGI and I'm having a hard time understanding the problem here. I'm
>>> running OpenBSD 7.
>>
>> I think you are stuck because you tried a mix of fastcgi and plain
>> cgi. The simple CGI script I showed will not work for FastCGI or
>> SCGI.
>
> I got puzzled there, but I'll let that one go and try your next
> suggestions.

FastCGI and SCGI are ways of making basic CGI 'faster' in a high load
environment.

Unless all your students all try to upload exactly one minute before
any deadline, you likely don't need the performance boost from either.
And, even then, unless you have enough students or a very underpowered
system, the load likely won't cause any harm.

Look into how to enable plain, basic, standard, CGI with nginx. There
is likely some way to do so (I don't run nginx, so I can't provide any
advice as to 'what' to do).

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>As an alternative, you could look into one of the many "revision control"
>systems. I'm thinking specifically of git or cvs, both of which can handle
>networked commits.
>
>In theory, your students would "commit" their homework to your repository,
>and you could then "pull" the homework out to be evaluated. Such revision
>control systems include user privilege management that you may be able
>to use to limit a student's ability to, for instance, "commit" to another
>student's homework, or "pull" another student's homework for copying.

Not only that, but the student can pull a framework and a datafile,
write the code and push that back. Permissions will keep them from
pushing a new datafile to screw up other students.

This is by far the best idea so far, and part of what makes it so good is
that it's bidirectional and any changes can be seen and rolled back. But
another part of why it's so good is that in the real world students will
find themselves having to work this way so they might as well get used to
it as quickly as possible.

If it were me I would recommend svn or git. They both are very good for
teaching the basic source code control concepts, but unfortunately they
use totally different language in their documentation to mean the same
things. This means moving from one to the other can be confusing even
though in the end they really do the same things underneath.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Meredith Montgomery <mmontgomery@levado.to> wrote:
>
>I can't run a MTA in this server because e-mail ports are blocked by the
>ISP. I can pay more and get that out of the way, though.

Your ISP sure has an awful lot of spammers using their service, though.
Maybe they only allow outgoing mail and not incoming? Perhaps you should
get a competent ISP.

>But it seems you mean you had a script that would look into an inbox and
>extract homework from messages. But my mail is not in the UNIX system.

There's your problem, right there.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

kludge@panix.com (Scott Dorsey) writes:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>As an alternative, you could look into one of the many "revision control"
>>systems. I'm thinking specifically of git or cvs, both of which can handle
>>networked commits.
>>
>>In theory, your students would "commit" their homework to your repository,
>>and you could then "pull" the homework out to be evaluated. Such revision
>>control systems include user privilege management that you may be able
>>to use to limit a student's ability to, for instance, "commit" to another
>>student's homework, or "pull" another student's homework for copying.
>
> Not only that, but the student can pull a framework and a datafile,
> write the code and push that back. Permissions will keep them from
> pushing a new datafile to screw up other students.
>
> This is by far the best idea so far, and part of what makes it so good is
> that it's bidirectional and any changes can be seen and rolled back. But
> another part of why it's so good is that in the real world students will
> find themselves having to work this way so they might as well get used to
> it as quickly as possible.

You're totally right. The best idea and, indeed, they should get
exposed to such tools. (It's the real world.)

> If it were me I would recommend svn or git. They both are very good for
> teaching the basic source code control concepts, but unfortunately they
> use totally different language in their documentation to mean the same
> things. This means moving from one to the other can be confusing even
> though in the end they really do the same things underneath.
> --scott

I'm well used to git, but fossil seems rather simple to use, too, and it
comes ready with this nice web interface too --- which I believe will be
very useful for students to understand the commands they type.

Rich <rich@example.invalid> writes:

> Meredith Montgomery <mmontgomery@levado.to> wrote:
>> Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>>
>>> On Wed, 07 Sep 2022 16:03:09 -0300, Meredith Montgomery
>>> <mmontgomery@levado.to> wrote:
>>>
>>> [...]
>>>
>>>> I'm running nginx. So I'm gonna have to learn how to run at least one
>>>> CGI and I'm having a hard time understanding the problem here. I'm
>>>> running OpenBSD 7.
>>>
>>> I think you are stuck because you tried a mix of fastcgi and plain
>>> cgi. The simple CGI script I showed will not work for FastCGI or
>>> SCGI.
>>
>> I got puzzled there, but I'll let that one go and try your next
>> suggestions.
>
> FastCGI and SCGI are ways of making basic CGI 'faster' in a high load
> environment.
>
> Unless all your students all try to upload exactly one minute before
> any deadline, you likely don't need the performance boost from either.
> And, even then, unless you have enough students or a very underpowered
> system, the load likely won't cause any harm.
>
> Look into how to enable plain, basic, standard, CGI with nginx. There
> is likely some way to do so (I don't run nginx, so I can't provide any
> advice as to 'what' to do).

Like someone here has said, it seems nginx doesn't support the classic
CGI. They support fastCGI and SCGI. I'm out of luck there. My hope is
that I can run another web server that does CGI --- run it in at port X
--- and then have nginx act as a proxy for it. (Just so I don't have to
replace nginx completely.)

kludge@panix.com (Scott Dorsey) writes:

> Meredith Montgomery <mmontgomery@levado.to> wrote:
>>
>>I can't run a MTA in this server because e-mail ports are blocked by the
>>ISP. I can pay more and get that out of the way, though.
>
> Your ISP sure has an awful lot of spammers using their service, though.
> Maybe they only allow outgoing mail and not incoming? Perhaps you should
> get a competent ISP.

I think they think their price is really low and spammers would buy
these servers just to send out mail. I've no idea. It's what it is. I
don't mind paying more for a nice server. But we gotta do one thing at
a time.

>>But it seems you mean you had a script that would look into an inbox and
>>extract homework from messages. But my mail is not in the UNIX system.
>
> There's your problem, right there.
> --scott

Lol. We can agree on that.

Meredith Montgomery <mmontgomery@levado.to> writes:

> Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>
>> On Wed, 07 Sep 2022 16:03:09 -0300, Meredith Montgomery
>> <mmontgomery@levado.to> wrote:
>>
>> [...]
>>
>>> I'm running nginx. So I'm gonna have to learn how to run at least one
>>> CGI and I'm having a hard time understanding the problem here. I'm
>>> running OpenBSD 7.
>>
>> I think you are stuck because you tried a mix of fastcgi and plain
>> cgi. The simple CGI script I showed will not work for FastCGI or
>> SCGI.
>
> I got puzzled there, but I'll let that one go and try your next
> suggestions.
>
>> Not running nginx myself I can only refer to this matrix :
>> https://www.fossil-scm.org/home/doc/trunk/www/server/#matrix
>>
>> [...]
>>
>>> I'll run lighthttpd if I have to.
>>
>> For small scale sites lighttpd is pretty good.
>> Another, even lighter alternative is althttpd.
>> https://sqlite.org/althttpd/
>> (A single C-source you can compile yourself)
>
> Sounds good. But I would not like to replace nginx completely because
> it answers many other hostnames. I'm thinking I can use nginx as a
> proxy to althttpd --- just so I don't have to ask users to memorize port
> numbers in their web addresses. I'll try that. (I like the
> single-source I can compile myself.)

I have a few small victories. At first glance, althttpd has a weak
error reporting. It silently refuses to do some impossible things.
With some trial and error, I managed to see what it wanted.

I asked nginx to be a proxy for althttpd.

What's the new obstacle? I must find a way to tell fossil that the base
URL is another one. It is trying to load CSS from
http://localhost:1234. That's wrong. It should try to load it from
https:/my.host.name/style.css. Fossil's /server/ command accepts the
option --baseurl URL, which I've used before when I was running fossil's
server stand-alone. Now I must somehow instruct fossil's CGI script. I
wonder how.

Meredith Montgomery <mmontgomery@levado.to> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>>
>>> On Wed, 07 Sep 2022 16:03:09 -0300, Meredith Montgomery
>>> <mmontgomery@levado.to> wrote:
>>>
>>> [...]
>>>
>>>> I'm running nginx. So I'm gonna have to learn how to run at least one
>>>> CGI and I'm having a hard time understanding the problem here. I'm
>>>> running OpenBSD 7.
>>>
>>> I think you are stuck because you tried a mix of fastcgi and plain
>>> cgi. The simple CGI script I showed will not work for FastCGI or
>>> SCGI.
>>
>> I got puzzled there, but I'll let that one go and try your next
>> suggestions.
>>
>>> Not running nginx myself I can only refer to this matrix :
>>> https://www.fossil-scm.org/home/doc/trunk/www/server/#matrix
>>>
>>> [...]
>>>
>>>> I'll run lighthttpd if I have to.
>>>
>>> For small scale sites lighttpd is pretty good.
>>> Another, even lighter alternative is althttpd.
>>> https://sqlite.org/althttpd/
>>> (A single C-source you can compile yourself)
>>
>> Sounds good. But I would not like to replace nginx completely because
>> it answers many other hostnames. I'm thinking I can use nginx as a
>> proxy to althttpd --- just so I don't have to ask users to memorize port
>> numbers in their web addresses. I'll try that. (I like the
>> single-source I can compile myself.)
>
> I have a few small victories. At first glance, althttpd has a weak
> error reporting. It silently refuses to do some impossible things.
> With some trial and error, I managed to see what it wanted.
>
> I asked nginx to be a proxy for althttpd.
>
> What's the new obstacle? I must find a way to tell fossil that the base
> URL is another one. It is trying to load CSS from
> http://localhost:1234. That's wrong. It should try to load it from
> https:/my.host.name/style.css. Fossil's /server/ command accepts the
> option --baseurl URL, which I've used before when I was running fossil's
> server stand-alone. Now I must somehow instruct fossil's CGI script. I
> wonder how.

I was a bit in the wrong direction. I gave up on althttpd, then used
fossil stand-alone server and used nginx as a proxy server. Running
fossil's stand-alone web server, I was able to specify the --baseurl
option. We're done. Now I need to just study enough of fossil to set
up users and begin using it. Phew! That was a lot of work! Very hard
to get it done. Thank you so much for your attention. You're great!

On Wed, 07 Sep 2022 20:59:17 -0300, Meredith Montgomery
<mmontgomery@levado.to> wrote:

> I'm well used to git, but fossil seems rather simple to use, too, and it
> comes ready with this nice web interface too --- which I believe will be
> very useful for students to understand the commands they type.

And when you need it, fossil includes ticketing, a forum and a
developer chat room. All in that same one executable.

For projects like this, I would add one fossil repository for a
forum for all students, a forum per student would be a bit
silly.

I'm glad you are making progress, nginx can be a tough cookie.

--
Kees Nuyt

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:

> On Wed, 07 Sep 2022 20:59:17 -0300, Meredith Montgomery
> <mmontgomery@levado.to> wrote:
>
>> I'm well used to git, but fossil seems rather simple to use, too, and it
>> comes ready with this nice web interface too --- which I believe will be
>> very useful for students to understand the commands they type.
>
> And when you need it, fossil includes ticketing, a forum and a
> developer chat room. All in that same one executable.

Yeah, in fact it even seems like too much. <sarcasm>Let's write an
email to the author (not open a ticket!) asking him to, please,
*enhance* the software with an embedded NNTP server (and client, please)
because *we personally believe* that NNTP is clearly the
future.</sarcasm>

> For projects like this, I would add one fossil repository for a
> forum for all students, a forum per student would be a bit
> silly.

It would. That's an idea, but if I were to offer them a forum, I'd take
the opportunity and present NNTP to them: I doubt they'd have a second
chance to get to know it.

> I'm glad you are making progress, nginx can be a tough cookie.

I'm glad you're here! It's tough to think by oneself. (Thank you!)

Meredith Montgomery <mmontgomery@levado.to> wrote:
> Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>
>> On Wed, 07 Sep 2022 20:59:17 -0300, Meredith Montgomery
>> <mmontgomery@levado.to> wrote:
>>
>>> I'm well used to git, but fossil seems rather simple to use, too, and it
>>> comes ready with this nice web interface too --- which I believe will be
>>> very useful for students to understand the commands they type.
>>
>> And when you need it, fossil includes ticketing, a forum and a
>> developer chat room. All in that same one executable.
>
> Yeah, in fact it even seems like too much. <sarcasm>Let's write an
> email to the author (not open a ticket!) asking him to, please,
> *enhance* the software with an embedded NNTP server (and client, please)
> because *we personally believe* that NNTP is clearly the
> future.</sarcasm>

The author of Fossil is also the author of SQLite.

But in any case, if you consider Fossil's intended use case:
distributed software development by a team of open source/free software
developers, most of those projects are going to want one or more of:

Source control, trouble/bug tickets, a website, a forum, etc...

Fossil is simply combining, into a single module, most of the common
items that "distributed open source development teams" will want,
obviating the need to deploy each individually and separately.

So the 'combination', looked at in the light of the intended use, has
some logic behind it. It is an "all in one, non-proprietary,
solution" for distributed software development.

Rich <rich@example.invalid> writes:

> Meredith Montgomery <mmontgomery@levado.to> wrote:
>> Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>>
>>> On Wed, 07 Sep 2022 20:59:17 -0300, Meredith Montgomery
>>> <mmontgomery@levado.to> wrote:
>>>
>>>> I'm well used to git, but fossil seems rather simple to use, too, and it
>>>> comes ready with this nice web interface too --- which I believe will be
>>>> very useful for students to understand the commands they type.
>>>
>>> And when you need it, fossil includes ticketing, a forum and a
>>> developer chat room. All in that same one executable.
>>
>> Yeah, in fact it even seems like too much. <sarcasm>Let's write an
>> email to the author (not open a ticket!) asking him to, please,
>> *enhance* the software with an embedded NNTP server (and client, please)
>> because *we personally believe* that NNTP is clearly the
>> future.</sarcasm>
>
> The author of Fossil is also the author of SQLite.
>
> But in any case, if you consider Fossil's intended use case:
> distributed software development by a team of open source/free software
> developers, most of those projects are going to want one or more of:
>
> Source control, trouble/bug tickets, a website, a forum, etc...
>
> Fossil is simply combining, into a single module, most of the common
> items that "distributed open source development teams" will want,
> obviating the need to deploy each individually and separately.
>
> So the 'combination', looked at in the light of the intended use, has
> some logic behind it. It is an "all in one, non-proprietary,
> solution" for distributed software development.

It's really great.

Meredith Montgomery <mmontgomery@levado.to> writes:

[...]

> I'll write again. (More later!)

I think I'm done. Here's my script. Let /r/ represent the path that
represents the student's repository. I create it with

fs init $r

Since I created it, I'm the owner --- capability /s/. I open $r, create
a user for the student with

fs user new username email password

I give the student enough permission (no category involved)

fs user capabilities jpmab beghiopxz

Now I remove all public access with

fossil user capabilities anonymous ''
fossil user capabilities nobody ''
fossil user capabilities reader ''
fossil user capabilities developer ''

Now I have full privileges and the user is a reader /union/ developer.

Finally, I give it a nice random project name as a warm welcome to the
student.

fossil sqlite -R $r \
"replace into config (name, value, mtime) \
values ('project-name', 'Nice Name', now());"

That's it. Should I close it now --- because I opened it? I'm not
sure. I'm not quite sure what open or close really do.

I think that's it. Thank you again!