Re: TCL in a chroot
> 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
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
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
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
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)
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)
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 } }