Re: TCL in a chroot

[Paul Pereira]

> have you run ldconfig?
...
> that should create /var/www/var/run/ld.so.hints which aids the linker in
> locating the shared libs.

Thanks Dan, I hadn't.

TCL in a chroot

[Paul Pereira]

Has anyone had luck running tcl within a chroot? I have the required
libraries reported by ldd in place, but the interpreter cannot find
them.

# chroot /var/www /usr/local/bin/tclsh8.5
/usr/local/bin/tclsh8.5: can't load library 'libtcl85.so.1.7'

# ldd `which tclsh8.5`
/usr/local/bin/tclsh8.5:
StartEnd  Type Open Ref GrpRef Name
1a646000 3a64a000 exe  10   0  /usr/local/bin/tclsh8.5
0c0e6000 2c105000 rlib 01   0  /usr/local/lib/libtcl85.so.1.7
0a26d000 2a276000 rlib 02   0  /usr/lib/libm.so.9.0
0ce86000 2cea4000 rlib 01   0  /usr/lib/libc.so.80.1
02688000 02688000 rtld 01   0  /usr/libexec/ld.so

# ls /var/www/usr/local/lib/libtcl85.so.1.7
/var/www/usr/local/lib/libtcl85.so.1.7

Regards,
Paul

Re: Meta key within mg/xterm/cwm

[Paul Pereira]

Hi Nicholas,

Thanks, this in .Xdefaults did the trick:

XTerm*eightBitInput:   false
XTerm*eightBitOutput:  true


On 20 July 2015 at 19:38, Nicholas Marriott nicholas.marri...@gmail.com wrote:
 Hi

 Are xterm(1) eightBitInput and eightBitControl turned off?

Meta key within mg/xterm/cwm

[Paul Pereira]

I am unable to isolate a problem with the meta key.  When running mg
within a console M-x theo behaves correctly, but within cwm/xterm it
produces heo.  Similarly, M-q in the console will fill a
paragraph, but within cwm it will capitalize the letter under point.
Other meta key combinations are similarly broken.

What I have tried:
1. Explicitly unbinding M-q from cwm, even though it should not be bound:
bind M-q unmap   (in cwmrc)
2. Switching the Alt_L key to a proper Meta_L key and verifying its
operation with xev.
keysym Alt_L = Meta_L Alt_L (with xmodmap)

A few notes about my setup:
- I use a custom X keyboard layout (Colemak), but according to xev
this keyboard layout is fine.
- I have the same problem on an X60 Tablet, an Asus 1001p Eee PC, and
an Intel NUC.

I cannot quite isolate the problem, so any suggestions would be appreciated.

Regards,
Paul Pereira

Re: IBM ThinkPad X60s 1704-5LG flashed with coreboot SeaBIOS

[Paul Pereira]

This is fantastic.  Is there a high pitched-noise from the board?  I
find that with Trisquel, I really needed a tool like powertop to tweak
settings in order to make the machine quiet.

 System boots just fine - (previously it would hang on probing CPU, 4
 months ago)
 Sleep /Wake works
 X11 works

fastcgi (without slowcgi)

[Paul Pereira]

T.

Seeing the unix socket file is a good sign. Try debugging by running
httpd -dvvv so that you can see all the error messages in the console.

 The script does not return, which is probably because of the while
 loop waiting for a new connection. However, in a second shell I can
 see that this time the socket was created:

 # ls -ld /var/www/run/slowcgi.sock
 srwxr-xr-x  1 www  www  0 May 24 13:46 /var/www/run/slowcgi.sock

I do not see in the documentation that httpd can manage the fcgi
application itself. It is not required by the protocol. Some web
servers do have that functionality, as does the program spawn-fcgi.

 So the socket file is not being created when the script was started
 from httpd.

Regards,

Paul

fastcgi (without slowcgi)

[Paul Pereira]

Hi T.

I warn you that I am no unix/security expert. The following should be
reviewed by somebody with more experience, especially with regard to
permissions.

Nevertheless, I did manage to get fcgi running on 5.7.  In my case I
used C/Luajit/FCGX. I used the FCGX headers in fcgiapp.h rather than
fcgi_stdio.h because the normal interface uses several macros that
do not play nice with luajit.

It is likely that the problem is with permissions or with the chroot
environment. OpenBSD's documentation is great, but doing this correctly
is tricky.

I believe that your script needs to be able to create a file in its
/run directory, so it needs permission to be able to do that.  httpd
does not create the socket there by itself. I think by default, the
www user does not have permission to create a unix socket here.

In order to get the chroot working I did the following:

I started by compiling a simple C test example to minimize
dependencies.  Make sure this example works as a
standard CGI program from the command line. Make sure that it can
create a unix domain socket.

Then I tested the chroot environment from the command line, using
ldd on the executable to understand exactly what dynamic libraries
it loaded and where they expect to be found. For example, in my case
I needed libc and libm in a /usr/lib subdirectory. I did this
locally in my home directory to so that there were no
permissions issues.

Then I tested the program chrooted to /var/www/[progroot]/ . I used a
subdirectory because I didn't want all of the libraries used to be
visible to every chrooted FCGI program ... and because my site needs a
LOT of space.  Make sure that the program is started as the correct
user, e.g.

chroot -g www -u www /var/www/progroot/ /bin/progname ... arguments

If the program requires any devices like /dev/null, then there is more
work to be done, which is complicated by the fact that non-root
partitions are mounted with the nodev (no device) option. In my case,
my fcgi program runs from a separate partion at /var/www/[progname],
so I could change this if it were necessary (it isn't).

Then, httpd worked like a charm:

/etc/httpd:
...
server default {
listen on  tls port 443
tls certificate 
tls key 
location /* {
   fastcgi socket /[progroot]/run/test.sock
}
}