Announcing cgid v0.1.0

[fREW Schmidt]

A week or two ago I emailed this list asking about httpds that
support CGI and run under UCSPI.  Sadly everything that I found or was
recommended either missed critical features or was defunct.  So like
any good programmer I made a new thing!

Announcing cgid: I have just released the first version (v0.1.0) of
cgid, which supports a very basic but sufficient amount of CGI.  I am
already using it myself.  To read the docs check out
https://github.com/frioux/cgid/releases/download/v0.1.0/cgid-v0.1.0,
where you can see examples of how to run under `nosh` or `s6`.

There are a number of bugs and limitations, also listed on that page.

Thanks
-- 
fREW Schmidt
https://blog.afoolishmanifesto.com

Ideas for triggering updates?

[fREW Schmidt]

I've been enjoying using UCSPI based services because updates become
*pretty* simple.  For example here's the code I use to update my git
based project automatically:

  system qw(git fetch);
  system qw(git reset --hard @{upstream});

(see
https://github.com/frioux/Lizard-Brain/blob/master/www/cgi-bin/impulse-www#L70)

The problem is, if one of the services `run` files changes this will
not affect the running services (which includes the www service.)  I
know I could force the running supervisor (runsvdir currently) to
restart but the http response would end up being a 502 because the www
service would exit before writing the response.

Anyone have any ideas or nice patterns for this?

-- 
fREW Schmidt
https://blog.afoolishmanifesto.com

Re: UCSPI httpd?

[fREW Schmidt]

That is what I remember, but sadly: "publicfile never runs any other
programs. It does not support HTTP CGI or FTP SITE EXEC."

I'll implement my own unless someone knows of another one that supports CGI.

On Sat, Jan 23, 2016 at 9:44 AM, Brian Reichert <reich...@numachi.com>
wrote:

> On Sat, Jan 23, 2016 at 09:32:45AM -0800, fREW Schmidt wrote:
> > I *know* that at some point I read about an httpd (using CGI) that
> > worked with UCSPI; anyone know where that would have been?  I figure I
> > could implement one myself but surely one already exists.
>
> At some point, DJB wrote 'publicfile':
>
>   https://cr.yp.to/publicfile.html
>
>   https://cr.yp.to/publicfile/install.html
>
>   publicfile uses ucspi-tcp to handle incoming HTTP and FTP
>   connections.  Before installing publicfile you need to install
>   ucspi-tcp 0.83 or above.  Make sure that the ucspi-tcp programs
>   are in your system's default path.
>
> Is that what you're looking for?
>
> > --
> > fREW Schmidt
> > https://blog.afoolishmanifesto.com
>
> --
> Brian Reichert  <reich...@numachi.com>
> BSD admin/developer at large
>



-- 
fREW Schmidt
http://blog.afoolishmanifesto.com

UCSPI httpd?

[fREW Schmidt]

I *know* that at some point I read about an httpd (using CGI) that
worked with UCSPI; anyone know where that would have been?  I figure I
could implement one myself but surely one already exists.
-- 
fREW Schmidt
https://blog.afoolishmanifesto.com

Re: UCSPI httpd?

[fREW Schmidt]

Sadly busybox httpd only supports a hardcoded list of Request headers.
I'll send an email about that to their ML.  Trying fnord next.

On Sat, Jan 23, 2016 at 11:43 AM, Laurent Bercot <
ska-supervis...@skarnet.org> wrote:

> On 23/01/2016 18:44, Brian Reichert wrote:
>
>>https://cr.yp.to/publicfile.html
>>
>
>  publicfile only serves static files, it doesn't support CGI.
>
>  I had a patch for it to implement CGI support, but it was
> rather ugly. I dropped it long ago.
>
>  I'm now using busybox httpd, which does exactly what I want:
> UCSPI support ("inetd mode"), CGI support, and a bit of
> easy configuration.
>
> --
>  Laurent
>
>


-- 
fREW Schmidt
http://blog.afoolishmanifesto.com

Re: How to compile nosh?

[fREW Schmidt]

Thanks Guillermo and Jonathan, your tips got me where I needed to be.

-- 
fREW Schmidt
https://blog.afoolishmanifesto.com

How to compile nosh?

[fREW Schmidt]

Nosh only has binaries compiled for 64 bit and my linode is sadly
still 32 bit.  So I'm trying to build nosh for 32 bit, but I'm running
into trouble.

First off, there's no README or anything, so I sorta have to guess.

I tried running source/all.do and got an error about about
redo-ifchange not existing.  Ok, I vaguely remember this make
replacement called redo, so I go to install that and ofc I now need to
compile that because there are only 64 bit binaries for that too.

I tried building redo, but running source/compile, but then got errors
about no ./cxx or ./cxxflags.  I made ./cxx a symlink to g++ but I
have no idea what to put in cxxflags.  Again there's no README for
redo.

I really like the vision of nosh, but these kinds of issues add enough
friction that I am likely to reconsider using it.  s6 is also not
packaged for debian/ubuntu, but at least it uses more typical tools,
like make, for compilation, as well as including a README and not
being packaged as a tarbomb (more than one top level subdir in the
tarball.)
-- 
fREW Schmidt
https://blog.afoolishmanifesto.com

Re: Supervising a pipeline?

[fREW Schmidt]

Two things:

I'm not at a computer but I'm *pretty* sure exec foo | bar doesn't work
right?

But more importantly, if the python program dies, the inotifywatch will get
a SIGPIPE when it writes and then almost assuredly crash itself. You could
kill the python program and see.

-- 
sent from a rotary phone, pardon my brevity
On Dec 26, 2015 11:07 AM, "Steve Litt"  wrote:

> Hi all,
>
> I'm making a thumb drive automounter using inotifywait piped into my
> Python program, which detects the proper CREATES and DELETES and
> automounts and autoumounts accordingly.
>
> Here's what I thought the run script would look like (runit dialect):
>
> #!/bin/sh
> exec /usr/bin/inotifywait /dev/disk | /usr/local/bin/automounter.py
>
> However, it was pointed out to me that if automounter.py crashed,
> inotifywait would keep spinning and shooting its voluminous stdout
> messages into the ether. And presumably the service wouldn't crash and
> restart.
>
> Is this doable in a way consistent with supervision suites?
>
> I completely understand that 95% of you think what I've suggested is a
> no-style kludge that shouldn't be done, and that I should use Python's
> inotify framework. This is a completely different discussion: I'm
> limiting my question to whether such a pipeline is, or can be made,
> consistent with things like daemontools-encore, s6, and runit.
>
> Thanks,
>
> SteveT
>
> Steve Litt
> November 2015 featured book: Troubleshooting Techniques
>  of the Successful Technologist
> http://www.troubleshooters.com/techniques
>