Recent regression in SSL session reuse
After an OpenBSD upgrade, one of Ruby's tests for SSL session
reuse started to fail. After some debugging, I have found that
if a maximum SSL version is not set by a client, then session
reuse does not work. Setting a minimum version does not have
an effect.
At the bottom of this email is an example Ruby program showing
the issue. If you save it to t.rb, you can then run:
pkg_add ruby%2.6
ruby26 t.rb
It will print out three lines, showing whether session reuse is
enabled:
1) When not setting max or min version
2) When setting max version
3) When setting min version
The behavior has changed recently, so I believe this to be a
regression. Older versions would allow reuse of sessions when the
max SSL version was not set, but newer versions only allow reuse of
sessions if setting the max SSL version.
OpenBSD 6.7-current (GENERIC.MP) #272: Mon Jun 15 01:54:58 MDT 2020
[nil, true]
["max", true]
["min", true]
OpenBSD 6.7-current (GENERIC) #325: Wed Jul 8 10:25:43 MDT 2020
OpenBSD 6.7-current (GENERIC.MP) #376: Mon Jul 27 11:51:27 MDT 2020
[nil, false]
["max", true]
["min", false]
So it looks like this behavior changed between June 15 and July 8.
If the Ruby program below is not sufficient to diagnose this issue,
please let me know and I'll see if I can translate it to C. I checked
and the min_version call is calling SSL_CTX_set_min_proto_version(3),
and that is the only change it makes.
Thanks,
Jeremy
# t.rb file:
require 'net/http'
[nil, 'max', 'min'].each do |meth|
http = Net::HTTP.new("google.com", 443)
http.use_ssl = true
if meth
http.send("#{meth}_version=", :TLS1)
end
http.start
http.get("/")
http.finish
http.start
http.get("/")
socket = http.instance_variable_get(:@socket).io
p [meth, socket.session_reused?]
end
Re: Recent regression in SSL session reuse
On 07/30 08:06, Theo Buehler wrote: > On Wed, Jul 29, 2020 at 02:57:33PM -0700, Jeremy Evans wrote: > > After an OpenBSD upgrade, one of Ruby's tests for SSL session > > reuse started to fail. After some debugging, I have found that > > if a maximum SSL version is not set by a client, then session > > reuse does not work. Setting a minimum version does not have > > an effect. > > This is an expected side-effect of switching TLS_method() to default to > TLSv1.3 > > https://github.com/openbsd/src/commit/94149d15d762bdbf7eef74c417c53d2b8dc7dd12 > > By setting the max version to TLSv1 with :TLS1 (or any of the other > defined versions :TLS1_1 or :TLS1_2), you use the legacy stack which > supports session resumption. The minimum version is already TLSv1, so > setting the minimum version to :TLSv1 has no effect. > > In TLSv1.3, the session resumption feature has been merged with > pre-shared keys, which we may eventually support, but that's not going > to happen very soon: > > https://tools.ietf.org/html/rfc8446#page-15 Theo, Thank you very much for the information. I'll try to get a change committed upstream now that I know the behavior is expected. Thanks, Jeremy
Re: Industrial use of line printers, does/would your company/organization use them with our lpd?
On Wed, Feb 17, 2016 at 9:28 PM, Andy Bradford wrote: > Anyway, just some musings. Is there anyone else out there using > lpr/lpd/lprm from base? Maybe I'm the only one? I've been using the lp* tools for many years for personal printing, first using a PostScript HP 4050dn and now using a Samsung M2830DW (with a filter from cups-filters). Jeremy
Re: OpenBSD + Firebird Server
On Tue, Nov 24, 2020 at 9:27 PM Radek wrote: > Hi, > is it possible to install Firebird Server in OpenBSD? I can't find any > info about that anywhere. > Thanks! Assuming you mean the SQL database, when last I looked into this years ago, Firebird required pthread_condattr_setpshared and pthread_mutexattr_setpshared, which OpenBSD doesn't implement. Thanks, Jeremy
Re: Ruby and OpenBSD 5.3
On Fri, Jun 7, 2013 at 8:51 PM, wrote: > Hello, > > Anybody manage to install Ruby 1.9.3 or 2.0.0 with rvm? It worked just > fine on 5.1. Have I missed anything in the changelog? > rvm is an external tool that builds ruby from source. In my experience, it doesn't work well on OpenBSD, as it mostly targets Mac OS X and Linux users. In any case, the OpenBSD developers do not support it. We encourage people to use precompiled packages built specifically for OpenBSD. There is a ruby 1.9.3 package for OpenBSD 5.3, and packages for both ruby 1.9.3 and 2.0.0 in -current. `sudo pkg_add -i ruby` Thanks, Jeremy
Re: Software caused connection abort (53) squid 4.6 on OpenBSD 6.5
On Thu, May 23, 2019 at 5:37 AM wrote: > I have been running into a repeatable error reported by squid 4.6 from > packages once the system has been under a steady load for ~12 hours. > I have also experienced this, though in my case the issue appeared to be isolated to a single site (which started working correctly after restarting). I'm considering downgrading squid locally to the version that shipped with 6.4 in order to work around the issue. Jeremy
Re: Route add - too many levels of symbolic links
On Wed, Sep 28, 2016 at 2:09 AM, Bryan Linton wrote: > On 2016-09-27 20:00:04, Dekker wrote: > > I have started encountering a wierd problem with my OpenBSD Laptop > > Running 6.0 Current (latest snapshot 25.09.2016) > > I run OpenVPN to connect this laptop to a remote server and I get the > > following output. > > > > [snip] > > > I also receive the 'Too many levels of symbolic links' errors when I > > connect to alternate (known working) OpenVPN servers. > > If I connect to these known working servers with my Android phone the > > route add command succeeds and I can access the interal networks behind > > the OpenVPN servers > > > > If I try to add these routes manually I get the same message: Too many > > levels of symbolic links. > > > > What could be the root cause of this issue? > > > > Please see this thread/post on ports@ > http://marc.info/?l=openbsd-ports&m=147385901603925&w=2 > > Note that sthen@ said he was looking at some other issues as > well, so this may not be the final patch that gets committed, but > it fixed OpenVPN for my use case at least. > > Your milage may vary. > Also, if you want a workaround without waiting for a patch, remove any route calls from your openvpn configuration, set script-security 2, and use an up script such as: #!/bin/sh /sbin/route add -net 123.45.67.0/24 $4 Thanks, Jeremy
Re: missing packages for SPARC
On Tue, Jan 13, 2015 at 12:58 PM, Riccardo Mottola < riccardo.mott...@libero.it> wrote: > do we really need bash to build ruby? and... why ruby for subversion? not > counting shells one ends up having perl, python, tcl and ruby! what a mess. You do need bash to build ruby 2.0, but not any earlier or later version. There were bugs in ruby 2.0's configure script, and they were unable to backport the necessary fixes to it. ruby is needed to build subversion for the ruby-subversion subpackage, but you can build with the no_ruby PSUEDO_FLAVOR to not require ruby or build that subpackage. Thanks, Jeremy
Re: Ruby 2.2.0 build fails on OpenBSD 5.5
On Mon, Jan 19, 2015 at 9:19 AM, wrote: > Hi! > > Anybody know why I'm getting this Ruby 2.2.0 build error? > > % uname -a > OpenBSD dev.my.domain 5.5 GENERIC#276 i386 > % ruby-install ruby 2.2.0 > ... > linking shared-object digest/sha2.so > installing default sha2 libraries > generating constant definitions > compiling etc.c > linking shared-object etc.so > compiling fcntl.c > linking shared-object fcntl.so > compiling fiber.c > linking shared-object fiber.so > *** Parse error in /home/dev/src/ruby-2.2.0/ext/fiddle: Wrong mix of > special targets (Makefile:370) > .PHONYclean-libffidistclean-libffirealclean-libffi > *** Parse error: Wrong mix of special targets (Makefile:371) > .PHONYclean-nonedistclean-nonerealclean-none > *** Parse error: Wrong mix of special targets (Makefile:377) > .PHONYconfigure > *** Error 1 in . (exts.mk:177 'ext/fiddle/all') > *** Error 1 in /home/dev/src/ruby-2.2.0 (Makefile:684 'build-ext') > !!! Compiling ruby 2.2.0 failed! > > Thanks! > > O.D. > > Our make doesn't handle some syntax they used in that file. I'm not sure if it's an issue with our make or a bug in exts.mk. It's currently patched out in the lang/ruby/2.2 port. Thanks, Jeremy
Re: problem building ruby on SPARC
On Tue, Mar 17, 2015 at 2:41 PM, Riccardo Mottola < riccardo.mott...@libero.it> wrote: > Hi, > > after a long pause, I was able to start work again with building > subversion and its dependencies on SPARC. > > I build bash in debug mode (python build was crashing). > Python built with success, whether the debug-version doesn't crash or the > new port does not need bash anymore I don't know. > > Ruby gets pulled in as a dependency to. Compilation succeeds, however > during package building I get this error: > > sed 's/INSTALL_ARGS/-c -o root -g bin/' < > /usr/ports/lang/ruby/2.1/../files/rbconfig_fix.rb > >> /usr/ports/pobj/ruby-2.1.5-no_ri_docs/fake-sparc-no_ri_docs/ > usr/local/lib/ruby/2.1/sparc-openbsd/rbconfig.rb > ===> Building package for ruby21-tk-2.1.5 > Create /usr/ports/packages/sparc/all/ruby21-tk-2.1.5.tgz > Error: Libraries in packing-lists in the ports tree >and libraries from installed packages don't match > --- /tmp/dep_cache.038S9OVYN/portstree-ruby21-tk-2.1.5 Tue Mar 17 > 00:47:26 2015+++ /tmp/dep_cache.038S9OVYN/inst-ruby21-tk-2.1.5 Tue Mar 17 > 00:47:32 2015@@ -4,5 +4,5 @@ > -W m.9.0 > -W pthread.18.0 > -W ruby21.1.0 > --W tcl85.1.6 > --W tk85.0.13 > +-W tcl85.1.5 > +-W tk85.0.12 > *** Error 1 in /usr/ports/lang/ruby/2.1 (/usr/ports/infrastructure/mk/ > bsd.port.mk:3225 'wantlib-args') > *** Error 1 in /usr/ports/lang/ruby/2.1 (/usr/ports/infrastructure/mk/ > bsd.port.mk:1944 '/usr/ports/packages/sparc/all/ruby21-tk-2.1.5.tgz') > > This indicates your ports tree is out of sync with the packages on your machine. If you don't want to fix that, you can set the PKG_CREATE_NO_CHECKS=Yes environment variable to work around this problem. Thanks, Jeremy
Use pax instead of cpio in FAQ 14.4 (Adding extra disks)
Two changes: 1) Switch from cpio -pdum to pax -rw -p e. cpio -pdum requires find which isn't available on bsd.rd, while pax -rw -p e works fine on bsd.rd. 2) Use a more complete example. I'm not sure if there are other reasons to use cpio over pax. However, when I replaced I disk last night and tried to use cpio to copy partitions, I noticed that it didn't work on bsd.rd. Thoughts/OKs? Jeremy Index: faq14.html === RCS file: /cvs/www/faq/faq14.html,v retrieving revision 1.202 diff -u -p -r1.202 faq14.html --- faq14.html 19 May 2010 12:41:02 - 1.202 +++ faq14.html 11 Jan 2013 20:19:16 - @@ -638,8 +638,14 @@ Finally, add it to What if you need to migrate an existing directory like /usr/local? You -should mount the new drive in /mnt and use cpio -pdum to copy /usr/local -to the /mnt directory. Edit the +should mount the new drive in /mnt and copy /usr/local to the /mnt directory. +Example: + + +# cd /usr/local && pax -rw -p e . /mnt + + +Edit the http://www.openbsd.org/cgi-bin/man.cgi?query=fstab&sektion=5";>/etc/fstab(5) file to show that the /usr/local partition is now /dev/sd2d (your freshly formatted partition). Example:
Re: Ruby 1.9.3 package on OpenBSD 5.9 (snapshots) missing
On Fri, Mar 18, 2016 at 10:49 AM, ML mail wrote: > Thanks for the info. I have now started to compile Ruby 1.9.3 on OpenBSD > 5.9 but face the following errors: > Check the port out of the CVS Attic, and try to built it via the ports system (it may need a few patches). Ruby 1.8.7 is still needed by other packages in the ports tree, which is why it is still in ports. Ruby 1.9.3 is not used by anything else in the ports tree, so it was removed after Ruby 2.0 was EOL. Thanks, Jeremy
Re: Printing problem
On Wed, Feb 19, 2014 at 11:20 AM, Chris Bennett <
chrisbenn...@bennettconstruction.us> wrote:
> I don't print from my laptop often, but all was fine until recently.
> I am at latest snapshot:
>
> OpenBSD 5.5-beta (GENERIC) #247: Fri Feb 7 12:04:52 MST 2014
> t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz ("GenuineIntel"
> 686-class) 2 GHz
> cpu0:
>
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,xTPR,PERF
> real mem = 536252416 (511MB)
> avail mem = 515588096 (491MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 01/12/04, BIOS32 rev. 0 @
> 0xffe90, SMBIOS rev. 2.3 @ 0xf76a0 (61 entries)
> bios0: vendor Dell Computer Corporation version "A10" date
> 01/12/2004
> bios0: Dell Computer Corporation Latitude C640
>
> When trying to print either through USB or network connection, I get
> this error:
>
> Your printer job (estimate_details_for_customer)
> had the following errors and may not have printed:
> No printer definition (option "-P ") specified!
>
> I did not have any problems previously. I haven't made any changes
> either.
> I am using commands of
> lpr -Plp estimate_details_for_customer
> or
> lpr -Paps1 estimate_details_for_customer
>
> Any advice?
>
Known issue with that snapshot. Already fixed in -current.
Re: Printing problem
On Fri, Feb 21, 2014 at 3:54 AM, Jan Stary wrote: > On Feb 19 13:20:07, chrisbenn...@bennettconstruction.us wrote: > > I don't print from my laptop often, but all was fine until recently. > > I did not have any problems previously. > > I haven't made any changes either. > > I am using commands of > > lpr -Plp estimate_details_for_customer > > or > > lpr -Paps1 estimate_details_for_customer > > On Feb 19 12:32:36, jeremyeva...@gmail.com wrote: > > Known issue with that snapshot. Already fixed in -current. > > Indeed. Out of curiosity, what was it? I couldn't find anything under > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/lpr/ > that would break and fix this. > Remote printing with lpd was broken from January 20 to February 7. usr.sbin/lpr/lpd/printjob.c (broken by r1.50, fixed by r1.52) Thanks, Jeremy
Re: sshd broken in today's snapshot?
On Fri, May 2, 2014 at 8:42 AM, Liviu Daia wrote: > Unless I'm doing something stupid, sshd seems to be broken in > today's snapshot. > > From a Linux machine: > > $ ssh testing > Connection to testing closed by remote host. > Connection to testing closed. > > From the server's point of view: > > # dmesg | head -1 > OpenBSD 5.5-current (GENERIC.MP) #95: Fri May 2 06:31:18 MDT 2014 > > # /usr/sbin/sshd -d > debug1: Enabling compression at level 6. [preauth] > Try disabling compression and see if that fixes it. Jeremy
Re: smtpd warn: not enough disk space
On Fri, Jul 5, 2024 at 9:16 PM Christian Schulte wrote: > Just wondering how the postgresql > port is configured. Really should setup quotas automatically when > pkg_adding in a way, just to ensure, that no one ever runs into a > situation, that there is no way out of a disk full situation. > I'm not aware of any port that sets up quotas automatically, so I don't understand why you think this is an issue with the PostgreSQL port specifically. Since you are wondering how the PostgreSQL port is configured: https://cvsweb.openbsd.org/ports/databases/postgresql/Makefile?rev=1.304&content-type=text/x-cvsweb-markup Jeremy
Re: postgresql-16.4 error on initdb
On 08/22 11:53, Markus Hennecke wrote: > Hello Jeremy, > > when trying to create a new postgresql 16.4 instance on -current I run into > this error: > > fixing permissions on existing directory /var/postgresql/data ... ok > creating subdirectories ... ok > selecting dynamic shared memory implementation ... posix > selecting default max_connections ... 100 > selecting default shared_buffers ... 128MB > selecting default time zone ... Europe/Berlin > creating configuration files ... ok > running bootstrap script ... ok > performing post-bootstrap initialization ... 2024-08-22 11:29:47.157 CEST > [54316] FATAL: syntax error at or near "FOR" at character 5 > 2024-08-22 11:29:47.157 CEST [54316] STATEMENT: FOR asciiword, > hword_asciipart, asciihword > WITH french_stem; > > child process exited with exit code 1 > initdb: removing contents of data directory "/var/postgresql/data" > > Existing databases from previous 16.x versions are working, it is only the > initdb step that is failing. > > I am pretty much lost how to proceed. The statement seems to be somewhere in > the middle of snoball_create.sql and I didn't see any obvious problems. I've had two separate reports with the same error when using initdb, part of PostgreSQL. These don't occur on an older snapshot when using PostgreSQL 16.4 (the version in -current), so something outside of PostgreSQL in -current in the last few days seems likely to be the cause. I will be doing some testing, but my guess is, the older version of PostgreSQL (16.3) also has the same issues on -current. Does anyone have an idea of what could have caused this? Thanks, Jeremy
Re: postgresql-16.4 error on initdb
On 08/22 03:43, Stuart Henderson wrote: > On 2024/08/22 14:14, Jeremy Evans wrote: > > On 08/22 11:53, Markus Hennecke wrote: > > > Hello Jeremy, > > > > > > when trying to create a new postgresql 16.4 instance on -current I run > > > into > > > this error: > > > > > > fixing permissions on existing directory /var/postgresql/data ... ok > > > creating subdirectories ... ok > > > selecting dynamic shared memory implementation ... posix > > > selecting default max_connections ... 100 > > > selecting default shared_buffers ... 128MB > > > selecting default time zone ... Europe/Berlin > > > creating configuration files ... ok > > > running bootstrap script ... ok > > > performing post-bootstrap initialization ... 2024-08-22 11:29:47.157 CEST > > > [54316] FATAL: syntax error at or near "FOR" at character 5 > > > 2024-08-22 11:29:47.157 CEST [54316] STATEMENT: FOR asciiword, > > > hword_asciipart, asciihword > > > WITH french_stem; > > > > > > child process exited with exit code 1 > > > initdb: removing contents of data directory "/var/postgresql/data" > > > > > > Existing databases from previous 16.x versions are working, it is only the > > > initdb step that is failing. > > > > > > I am pretty much lost how to proceed. The statement seems to be somewhere > > > in > > > the middle of snoball_create.sql and I didn't see any obvious problems. > > > > I've had two separate reports with the same error when using initdb, > > part of PostgreSQL. These don't occur on an older snapshot when using > > PostgreSQL 16.4 (the version in -current), so something outside of > > PostgreSQL in -current in the last few days seems likely to be the > > cause. I will be doing some testing, but my guess is, the older > > version of PostgreSQL (16.3) also has the same issues on -current. > > Confirmed, 16.3 does the same on -current. > > > Does anyone have an idea of what could have caused this? > > There were some libc changes, it may be a bit fiddly to test with > this as there was a bump, easiest way is probably to start with > say ftp.hostserver.de:/archive/2024-08-01-0105 on a scratch machine > (it has packages too), and move forwards between snapshots, testing > initdb each time. tb@ narrowed this down to the "Make exit(), fclose(), fflush(), and freopen() comply with POSIX-2008" commit. Reverting that commit fixes the issue. Thanks tb!
Re: in line anchor syntax error
On Thu, Apr 12, 2012 at 3:00 PM, Michel Blais wrote:
> Hi,
>
> I've read both pf anchor faq and pf.conf man page for 5.0 and my syntax seem
> right
> but I always get a error while trying to use ` in line anchor. The anchor
> line and
> closing bracket line both give me the syntax error with pfctl -vnf
> /etc/pf.conf
>
> I tryed with and without anchor name. Here a config test file I trying the
> anchor on :
> achor "test" in on em3 to {
My first guess would be using "achor" instead of "anchor".
Jeremy
Re: Download or Fetch Packages w/o Install?
On 10/15/07, Clint Pachl <[EMAIL PROTECTED]> wrote: > Is it possible to download a package and its dependencies, to PKG_CACHE > for instance, without installing anything? > > Just use pkg_add -n. It'll place the package and all dependencies in PKG_CACHE without actually installing the package or dependencies. Jeremy
Re: Lost Radeon Dual-Head after upgrade to 4.7
On Sat, May 22, 2010 at 4:45 PM, Vijay Sankar wrote: > Jeremy Evans wrote: >> >> After I upgraded to OpenBSD 4.7, my dual head configuration stopped >> working on my Radeon HD 2600 PRO. This has been working for about a >> year and a half with no problems since I got the video card. >> >> I tried various xrandr incantations to get it to work, but no luck. If >> I get the left monitor to work, the right monitor turns off, and vice >> versa. By default, with the xorg.conf including below, the right >> monitor displays output. With the following commands, I can make the >> left monitor display output, but then the right monitor turns off: >> >> xrandr --output DVI-1 --mode 1600x1200 >> xrandr --output DVI-1 --auto >> >> Both commands are needed, as with just the second, there is no change. >> If I run a command such as: >> >> xrandr --output DVI-0 --mode 800x600 >> >> The left monitor stops displaying, and the right monitor starts >> displaying. In both cases, xrandr shows both monitors as displaying, >> and I can move the mouse off one monitor to where the other monitor >> would be. >> >>> From CVS, it looks like the reason is that OpenBSD 4.4-4.6 uses >> >> xf86-video-ati 6.9.0, and OpenBSD 4.7 uses 6.12.2. >> >> I know new video drivers are often tried in snapshots for a few weeks >> before being committed to CVS. Any chance that current snapshots >> contain an updated version of xf86-video-ati? >> >> Any other advice about things to try to get the dual head configuration >> working? >> >> Thanks, >> Jeremy > Hi, > > Not sure whether this is of any use because my hardware is > > vga1 at pci3 dev 0 function 0 "ATI Radeon X1600" rev 0x9e > > but FWIW I have the following: > > SubSection "Display" >Depth 24 >Modes "1920x1080" "1680x1050" "1600x1200" "1280x1024" "1024x768" >Virtual 3840 3840 > EndSubSection > > and that works here. I went through a similar situation when I upgraded and > it took me a while to figure out that 3840 x 3840 worked. > > Vijay Thanks for the advice, but I get the same results with "Virtual 3840 3840". I also tried commenting out the "Viewport 0 0" line, with no effect. To give some more detail, I'm currently working in single monitor mode with the following lines in my .xinitrc: xrandr --output DVI-0 --off xrandr --output DVI-1 --mode 1600x1200 xrandr --output DVI-1 --mode 1920x1200 The first line turns off output the right monitor, as otherwise windows will still appear there. The second two lines are necessary to get the left monitor to work. With just the first line, nothing is output to either monitor. With just the last two lines, the left monitor works, the right monitor does not, but X11 still thinks the right monitor is connected. Jeremy
Re: Lost Radeon Dual-Head after upgrade to 4.7
On 05/23 02:50, Owain Ainsworth wrote: > On Sat, May 22, 2010 at 02:28:47PM -0700, Jeremy Evans wrote: > > After I upgraded to OpenBSD 4.7, my dual head configuration stopped > > working on my Radeon HD 2600 PRO. This has been working for about a > > year and a half with no problems since I got the video card. > > > > I tried various xrandr incantations to get it to work, but no luck. If > > I get the left monitor to work, the right monitor turns off, and vice > > versa. By default, with the xorg.conf including below, the right > > monitor displays output. With the following commands, I can make the > > left monitor display output, but then the right monitor turns off: > > > > xrandr --output DVI-1 --mode 1600x1200 > > xrandr --output DVI-1 --auto > > > > Both commands are needed, as with just the second, there is no change. > > If I run a command such as: > > > > xrandr --output DVI-0 --mode 800x600 > > > > The left monitor stops displaying, and the right monitor starts > > displaying. In both cases, xrandr shows both monitors as displaying, > > and I can move the mouse off one monitor to where the other monitor > > would be. > > > > From CVS, it looks like the reason is that OpenBSD 4.4-4.6 uses > > xf86-video-ati 6.9.0, and OpenBSD 4.7 uses 6.12.2. > > > > I know new video drivers are often tried in snapshots for a few weeks > > before being committed to CVS. Any chance that current snapshots > > contain an updated version of xf86-video-ati? > > > > Any other advice about things to try to get the dual head configuration > > working? > > Oh bloody wonderful. > > I hate it when they do that. > > I am currently chasing a bug in radeon 6.13.0 involving zaphod mode, but > after that we'll try and get that as the default. > > I can mail you offlist with a tarball of what we have so far, if you > wish. Owain, I tried to respond off-list, but haven't heard back. Anyway, I'd be happy to test the work in progress, please do send me the tarball. I assume I should upgrade to the latest snapshot first? Thanks, Jeremy
Re: ruby-thin: Errno::EPERM wtih QUIT Signal
On Wed, Feb 23, 2011 at 4:32 PM, Clint Pachl wrote:
> I use Thin (ruby-thin) as the HTTP frontend for my web frameworks.
>
> STARTING/STOPPING:
> $ sudo -u #{USER} thin -C #{THIN_PRODUCTION_CONF} start
> $ sudo -u #{USER} thin -C #{THIN_PRODUCTION_CONF} stop
>
>
> THIN_PRODUCTION_CONF:
> ---
> rackup: config/config.ru
> address: localhost
> port: 3020
> servers: 4
> max_conns: 1024
> max_persistent_conns: 512
> timeout: 30
> environment: production
> pid: tmp/thin-production.pid
> log: log/thin-production.log
> daemonize: true
>
>
> When sending the thin "stop" command, I get the following error on STDOUT:
>
> Stopping server on localhost:3020 ...
> Sending QUIT signal to process 15182 ...
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/daemonizing.rb:7:in
> `getpgid': Operation not permitted (Errno::EPERM)
>from
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/daemonizing.rb:7:in
> `running?'
>from
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/daemonizing.rb:118:in
> `send_signal'
>from /usr/local/lib/ruby/1.8/timeout.rb:67:in `timeout'
>from
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/daemonizing.rb:117:in
> `send_signal'
>from
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/daemonizing.rb:103:in
> `kill'
>from
>
/usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/controllers/controller.
rb:87:in
> `stop'
>from
>
/usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/controllers/controller.
rb:128:in
> `tail_log'
>from
>
/usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/controllers/controller.
rb:86:in
> `stop'
>from
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/runner.rb:177:in
> `send'
>from
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/runner.rb:177:in
> `run_command'
>from
> /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/runner.rb:143:in
> `run!'
>from /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/bin/thin:6
>from /usr/local/bin/thin:19:in `load'
>from /usr/local/bin/thin:19
>
>
> Here's a snipped from daemonizing.rb:
>
> 6: def running?(pid)
> 7:Process.getpgid(pid) != -1
> 8: rescue Errno::ESRCH
> 9:false
> 10: end
>
> As you can see, the ESRCH error is rescued here, which is the other error
> that getpgid(2) can return.
>
>
> Can anyone explain this?
Yes. The original author is not checking all of the errors he should
be checking. He should be rescuing Errno::EPERM and returning true, I
think.
Looks like a patch for exactly that was committed in June of last
year:
https://github.com/macournoyer/thin/blob/master/lib/thin/daemonizing.rb#L8
So thin should probably be updated after ports unlocks. I'll take care of
it.
Jeremy
Re: Passenger?
On Tue, Aug 11, 2009 at 12:35 PM, L. V. Lammert wrote: > Can seem to find anything in the archives, .. I just finished setting up a > Rails app under Passenger on a Linux box - pretty nice! We have a Rails > app running with Mongrel on 4.5, but I would really like to use an Apache > SSL session; never could get that working with mod_rewrite, however, when > we were trying last yeat. > > Are other folks using Passenger w/apache2, or is there another option for > Apache 1.3? I've tried out passenger on nginx, seems to work from my limited testing. The work in progress ports are at: http://gitorious.org/openbsd-ports-wip/mainline/trees/master/www/ruby-passenger http://gitorious.org/openbsd-ports-wip/mainline/trees/master/www/nginx I'm sure Bernd would appreciate more testing. Jeremy
Re: Kernel msg creating a ISO file from CD-ROM
On Sun, Sep 6, 2009 at 5:45 PM, Jesus Sanchez wrote: > on 4.5 stable. > > I'm using a CD drive with no problem until I need to create an ISO file > from a data CD-ROM for what I use this: > > # dd if=/dev/rcd0c bs=32k > image.iso You could try cdio(1): # man cdio # cdio cdrip
