Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[Philip Guenther]

On Tue, Feb 11, 2014 at 11:37 PM, RD Thrush  wrote:
...
> I didn't expect those perms to matter w/ Xorg -configure -keepPriv.

With the perms on /dev/drm[0-3] set so that you own them, what happens
when you don't use the -configure and -keepPriv options?

(You don't say why you use -configure, so I'll just quote Matthieu
Herb from July 2012(!):
> Also forget about X -configure. It's known to be more or less broken and 
> nowadays
> you don't need an xorg.conf file to run X in most cases.
)


Philip Guenther

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

On 02/11/14 19:45, Jonathan Gray wrote:
> On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote:
>> On 10 February 2014 13:11, RD Thrush  wrote:
>>> With a somewhat recent i7 desktop, using startx, X seems to run ok; 
>>> however, at 1024x768 rather than the expected 1920x1200 resolution. 
>>> ctl-alt-keypad+ or - have no effect on resolution.  ctl-alt-backspace  
>>> correctly reverts to text mode.  I then tried Xorg -configure to look for 
>>> hints to improve resolution; however, that resulted in a segfault almost 
>>> immediately.
>>>
>>
>> I'm pretty sure
>>
>> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
>>
>> is not supported in the sense of working as opposed to being
>> recognized. i.e. 1024x768 is likely as good as it gets until support
>> is added. Even 4400 is problematic at the moment.
>>
>> But I'm willing to be corrected by people more in the know. :-)
> 
> Haswell graphics should work since a few months now.

It does work; however, only @ vesa 1024x768 resolution.  That same hardware
yields 1920x1200 w/ win7.  Is 1024x768 the upper limit for -current w/ vga and
this graphics hardware?


> X segfaulting at a low address normally means the framebuffer
> could not be mmap'd due to the /dev/drm* permissions not
> being set correctly.

Here's what I have:
a8v2:home/rd 2181>ls -l /dev/drm*
crw---  1 root  wheel   87,   0 Jan 24 02:58 /dev/drm0
crw---  1 root  wheel   87,   1 Jan 24 02:58 /dev/drm1
crw---  1 root  wheel   87,   2 Jan 24 02:58 /dev/drm2
crw---  1 root  wheel   87,   3 Jan 24 02:58 /dev/drm3

I didn't expect those perms to matter w/ Xorg -configure -keepPriv.  In any
case, I added /dev/drm[123] to /etc/fbtab as you suggested in the other post but
observed the same segfault.

I had compiled xenocara w/ debug and included the gdb backtrace in the original
message[1].  How may I provide more info about this segfault?

[1]

Re: Starting cupsd by rc.d

[Antoine Jacoutot]

On Wed, Feb 12, 2014 at 01:37:51AM +0100, Stefan Wollny wrote:
> Am Wed, 12 Feb 2014 00:13:02 +0100
> schrieb Antoine Jacoutot :
> 
> > > Obviously cupsd is running as 'root' as it has been started by
> > > rc.local. If I remember right it used to be user '_cups' who exists:
> > 
> > Run the rc.d script in debug mode (i.e. -d) and you should be able to
> > see the output.
> > 
> 
> Hi Antoine (and 'Good Morning')!
> 
> I commented the lines in /etc/rc.local, deleted the entry of 'cupsd'
> in /etc/rc.conf.local and restarted. Et voilá:
> 
> ~~
>  $ sudo /etc/rc.d/cupsd -d start
> doing rc_read_runfile
> doing rc_check
> cupsd
> doing rc_pre
> "/etc/cups/cups-files.conf" is OK.
> "/etc/cups/cupsd.conf" is OK.
> rm: /var/cache/cups/rss: is a directory
> mv: rename /usr/bin/lpq to /usr/bin/lpq.pre-cups: Read-only file system
> mv: rename /usr/bin/lpr to /usr/bin/lpr.pre-cups: Read-only file system
> mv: rename /usr/bin/lprm to /usr/bin/lprm.pre-cups: Read-only file
> system mv: rename /usr/sbin/lpc to /usr/sbin/lpc.pre-cups: Read-only
> file system mv: rename /usr/sbin/lpd to /usr/sbin/lpd.pre-cups:
> Read-only file system mv: rename /usr/share/man/man1/lpq.1
> to /usr/share/man/man1/lpq.1.pre-cups: Read-only file system mv:
> rename /usr/share/man/man1/lpr.1 to /usr/share/man/man1/lpr.1.pre-cups:
> Read-only file system mv: rename /usr/share/man/man1/lprm.1
> to /usr/share/man/man1/lprm.1.pre-cups: Read-only file system mv:
> rename /usr/share/man/man8/lpc.8 to /usr/share/man/man8/lpc.8.pre-cups:
> Read-only file system mv: rename /usr/share/man/man8/lpd.8
> to /usr/share/man/man8/lpd.8.pre-cups: Read-only file system
> rm: /usr/bin/lpq: Read-only file system ln: /usr/bin/lpq: File exists
> rm: /usr/bin/lpr: Read-only file system ln: /usr/bin/lpr: File exists
> rm: /usr/bin/lprm: Read-only file system ln: /usr/bin/lprm: File exists
> rm: /usr/sbin/lpc: Read-only file system
> ln: /usr/sbin/lpc: File exists
> doing rc_post
> doing rc_rm_runfile
> (failed)
> ~~
> 
> OK: There seems to be an issue with /usr mounted -ro. I changed the
> setting in /etc/fstab to -rw and rebooted. Result:
> 
> ~~
> $ sudo /etc/rc.d/cupsd -d start
> doing rc_read_runfile
> doing rc_check
> cupsd
> doing rc_pre
> "/etc/cups/cups-files.conf" is OK.
> "/etc/cups/cupsd.conf" is OK.
> rm: /var/cache/cups/rss: is a directory
> doing rc_start
> doing rc_write_runfile
> (ok)
> ~~
> 
> Now I wanted to know if this was a one-time issue in the course of
> upgrading to the latest version of cups and switched back to
> mounting /usr '-ro'. After a restart I got:
> 
> ~~
> $ sudo /etc/rc.d/cupsd -d start
> doing rc_read_runfile
> doing rc_check
> cupsd
> doing rc_pre
> "/etc/cups/cups-files.conf" is OK.
> "/etc/cups/cupsd.conf" is OK.
> rm: /var/cache/cups/rss: is a directory
> doing rc_start
> doing rc_write_runfile
> (ok)
> ~~
> 
> So obviously my assumption that running the system with /usr mounted
> '-ro' should not affect /etc/rc.d-system was wrong for the case of
> upgrading an affected program like cupsd. PEBCAK.
> 
> As a final test I reactivated the start of cupsd in /etc/rc.conf.local
> with /etc/fstab unchanged (mounting /usr -ro). After a restart 'top'
> shows:
> ~~
> $ top | grep cups
> 24346 root   2 0 1696K 4344K idle  kqread0:00  0.00%   cupsd
> ~~
> 
> Here we go: cupsd is up and running. Printing is as expected.
> 
> Lesson learned: After upgrading it might be wise to once reboot off-line
> with /usr mounted '-rw' and switch back to mounting '-ro' afterwards
> being on-line.
> 
> Antoine: Thank you so much for your kind hint. For the records I
> documented a little more in detail what I did with this information
> hoping it will help others in similar situations.
> 
> (The only question left is why cupsd started from /etc/rc.local when
> failing to start from /etc/rc.d???)

The answer to that is what you posted at the very beginning of your mail.

-- 
Antoine

new queue bursting

[Ted Unangst]

How does bursting work in new queue? I'm unable to measure any effects.

For instance, I start with something like:

pass in on em0 proto tcp to port 80 queue web
queue rootq on em0 bandwidth 100M max 100M
queue web parent rootq bandwidth 10K max 5K
queue std parent rootq bandwidth 100M default

And sure enough, web downloads are crazy slow. So I tweak it:

pass in on em0 proto tcp to port 80 queue web
queue rootq on em0 bandwidth 100M max 100M
queue web parent rootq bandwidth 10K max 50K burst 100M for 100ms
queue std parent rootq bandwidth 100M default

Even small downloads are still crazy slow though, although I would
expect them to complete within 100ms at 100M.

What does it mean for a queue to "burst" and what is the meaning of
the duration? For 100ms per second? per connection? per ever?

Re: reach a remote LAN through IPSEC from the router

[andy]

Hi,

Reading this a bit late but something doesn't sound quite right. Just
ignore me if I'm reading this wrong..

An IPSec tunnel policy defines both the local network *and* the remote
network. So for a packet to be encrypted it must have both a source IP
address within the local subnet and a destination IP address within the
remote subnet according to the VPN policy (as seen with 'ipsecctl -sa').
The internet will also drop RFC1918 sourced packets anyway, but you don't
want to leak unencrypted packets.

If you want to send a packet from the local OpenBSD router itself to the
remote network securely you can simply add a static route on the local
OpenBSD router for the remote network to go via the local OpenBSD routers
internal interface's IP address.

This causes the packet generated by the local router to have its source IP
set to the IP of the internal interface. Assuming this internal interface
is within the local subnet defined by the VPN policy definition it will be
encrypted.

If I understand the suggestion the gre-tunnel idea can be useful of you
want the local carp-backup firewall in a CARP pair running sasyncd to also
be able to send packets itself to the remote network securely via the
tunnel (which of course needs to go via the local carp-master which holds
the current phase-1 trust). I don't believe sasyncd can fully syncronise
all of the phase 1 and 2 keys fully yet to allow the carp-backup to send
the packet itself directly without the remote resetting the trust.

Andy.


On Mon, 10 Feb 2014 21:48:27 -0800, Zach Leslie 
wrote:
> On Mon, Feb 10, 2014 at 07:58:39PM +0100, Aurelien Martin wrote:
>>  > net.inet.icmp.rediraccept=1 # 1=Accept ICMP redirects
>> 
>> Good to know this feature :)
>> 
>> > Are systems behind the firewall able to route to and reach the remote
>> network?
>> 
>> Yes all is working.
>> 
>> > we could route through the device, but packets that originated from
the
>> router were not able to make it through
>> 
>> This is also my case
>> 
>> >create a static route for the remote network to use the external
>> >interface
>> of the remote router as the gateway
>> 
>> Is it the best practice to create a static route to allow packet from
>> router (eg: for unbound) to reach the remote LAN ? Even with "ping"
>> Redirect Host "overhead"?
> 
> I can't say if this is the best practice, but it is one that works.
> Since you have the flows in place to know how to reach the remote router
> securely, the traffic should pop out the enc interface for filtering
> etc.  It does mean that you need to be a bit more aware of what the
> traffic is and how to filter it, since now to allow the router to
> communicate with a machine on the remote network, you must specify the
> external IP as the source, which offends me.
> 
> I can't confirm, but I also expect that this has some strange behavior,
> or poses the potential for traffic to be unencrypted, since you are
> manually specifying the routes.  If the IPSec is down, will traffic
> still flow?  And if it does, that means you are sending traffic in the
> clear across the untrusted network.  Less than ideal.  Something to keep
> in mind, and again, I've not confirmed thats the case.  This may be a
> problem only be for me in my test lab because the external interfaces
> were on the same network and my not be an issue when routing across the
> internet.
> 
> Another option you have, which I am not using yet, but like better, is
> to build a gre or gif tunnel over the ipsec.  This way as far as routes
> are concerned, all traffic is private in the rfc1918 space, or whatever,
> and shows up in the routing table in a neater way without routes leaving
> the private address space.  This means that the gre tunnel should be the
> only thing coming out of the enc interface, and then the traffic is
> unwrapped (un-tunneled?) on the gre interface.
> 
> This may yet be my approach, since I may need OSPF between sites, though
> I don't know how the carp will behave here.  I deploy my firewalls
> tomorrow morning, so its all still a work in progress.
> 
> Let us know how of any findings.

Re: Starting cupsd by rc.d

[Stefan Wollny]

Am Wed, 12 Feb 2014 00:13:02 +0100
schrieb Antoine Jacoutot :

> > Obviously cupsd is running as 'root' as it has been started by
> > rc.local. If I remember right it used to be user '_cups' who exists:
> 
> Run the rc.d script in debug mode (i.e. -d) and you should be able to
> see the output.
> 

Hi Antoine (and 'Good Morning')!

I commented the lines in /etc/rc.local, deleted the entry of 'cupsd'
in /etc/rc.conf.local and restarted. Et voilá:

~~
 $ sudo /etc/rc.d/cupsd -d start
doing rc_read_runfile
doing rc_check
cupsd
doing rc_pre
"/etc/cups/cups-files.conf" is OK.
"/etc/cups/cupsd.conf" is OK.
rm: /var/cache/cups/rss: is a directory
mv: rename /usr/bin/lpq to /usr/bin/lpq.pre-cups: Read-only file system
mv: rename /usr/bin/lpr to /usr/bin/lpr.pre-cups: Read-only file system
mv: rename /usr/bin/lprm to /usr/bin/lprm.pre-cups: Read-only file
system mv: rename /usr/sbin/lpc to /usr/sbin/lpc.pre-cups: Read-only
file system mv: rename /usr/sbin/lpd to /usr/sbin/lpd.pre-cups:
Read-only file system mv: rename /usr/share/man/man1/lpq.1
to /usr/share/man/man1/lpq.1.pre-cups: Read-only file system mv:
rename /usr/share/man/man1/lpr.1 to /usr/share/man/man1/lpr.1.pre-cups:
Read-only file system mv: rename /usr/share/man/man1/lprm.1
to /usr/share/man/man1/lprm.1.pre-cups: Read-only file system mv:
rename /usr/share/man/man8/lpc.8 to /usr/share/man/man8/lpc.8.pre-cups:
Read-only file system mv: rename /usr/share/man/man8/lpd.8
to /usr/share/man/man8/lpd.8.pre-cups: Read-only file system
rm: /usr/bin/lpq: Read-only file system ln: /usr/bin/lpq: File exists
rm: /usr/bin/lpr: Read-only file system ln: /usr/bin/lpr: File exists
rm: /usr/bin/lprm: Read-only file system ln: /usr/bin/lprm: File exists
rm: /usr/sbin/lpc: Read-only file system
ln: /usr/sbin/lpc: File exists
doing rc_post
doing rc_rm_runfile
(failed)
~~

OK: There seems to be an issue with /usr mounted -ro. I changed the
setting in /etc/fstab to -rw and rebooted. Result:

~~
$ sudo /etc/rc.d/cupsd -d start
doing rc_read_runfile
doing rc_check
cupsd
doing rc_pre
"/etc/cups/cups-files.conf" is OK.
"/etc/cups/cupsd.conf" is OK.
rm: /var/cache/cups/rss: is a directory
doing rc_start
doing rc_write_runfile
(ok)
~~

Now I wanted to know if this was a one-time issue in the course of
upgrading to the latest version of cups and switched back to
mounting /usr '-ro'. After a restart I got:

~~
$ sudo /etc/rc.d/cupsd -d start
doing rc_read_runfile
doing rc_check
cupsd
doing rc_pre
"/etc/cups/cups-files.conf" is OK.
"/etc/cups/cupsd.conf" is OK.
rm: /var/cache/cups/rss: is a directory
doing rc_start
doing rc_write_runfile
(ok)
~~

So obviously my assumption that running the system with /usr mounted
'-ro' should not affect /etc/rc.d-system was wrong for the case of
upgrading an affected program like cupsd. PEBCAK.

As a final test I reactivated the start of cupsd in /etc/rc.conf.local
with /etc/fstab unchanged (mounting /usr -ro). After a restart 'top'
shows:
~~
$ top | grep cups
24346 root   2 0 1696K 4344K idle  kqread0:00  0.00%   cupsd
~~

Here we go: cupsd is up and running. Printing is as expected.

Lesson learned: After upgrading it might be wise to once reboot off-line
with /usr mounted '-rw' and switch back to mounting '-ro' afterwards
being on-line.

Antoine: Thank you so much for your kind hint. For the records I
documented a little more in detail what I did with this information
hoping it will help others in similar situations.

(The only question left is why cupsd started from /etc/rc.local when
failing to start from /etc/rc.d???)

Hope you are all well!

STEFAN

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[Jonathan Gray]

On Tue, Feb 11, 2014 at 10:32:25AM -0500, RD Thrush wrote:
> On 02/10/14 13:20, Kenneth Westerback wrote:
> > On 10 February 2014 13:11, RD Thrush  wrote:
> >> With a somewhat recent i7 desktop, using startx, X seems to run ok; 
> >> however, at 1024x768 rather than the expected 1920x1200 resolution. 
> >> ctl-alt-keypad+ or - have no effect on resolution.  ctl-alt-backspace  
> >> correctly reverts to text mode.  I then tried Xorg -configure to look for 
> >> hints to improve resolution; however, that resulted in a segfault almost 
> >> immediately.
> >>
> > 
> > I'm pretty sure
> > 
> > vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
> > 
> > is not supported in the sense of working as opposed to being
> > recognized. i.e. 1024x768 is likely as good as it gets until support
> > is added. Even 4400 is problematic at the moment.
> > 
> > But I'm willing to be corrected by people more in the know. :-)
> > 
> >  Ken
> 
> Thanks for the feedback.  Apparently, Intel HD Graphics 4000 is similarly not 
> yet supported...

Ivy bridge works fine, what you didn't point out is that you
have both radeondrm and inteldrm in that machine.

Setups with multiple cards may have been broken by the fbtab changes

Try adjust your /etc/fbtab along these lines and restart your xorg server.

--- fbtab.prev  Wed Feb 12 11:46:14 2014
+++ fbtab   Wed Feb 12 11:47:15 2014
@@ -2,6 +2,6 @@
 # login(1) reads this file to determine which devices should be chown'd to
 # the new user. Format is:
 # login-ttypermdevice:[device]:...
-/dev/ttyC0 0600
/dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0
+/dev/ttyC0 0600
/dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0:/dev/drm1:/dev/drm2:/dev/drm3
 # samples
 #/dev/ttyC00600/dev/fd0

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[Jonathan Gray]

On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote:
> On 10 February 2014 13:11, RD Thrush  wrote:
> > With a somewhat recent i7 desktop, using startx, X seems to run ok; 
> > however, at 1024x768 rather than the expected 1920x1200 resolution. 
> > ctl-alt-keypad+ or - have no effect on resolution.  ctl-alt-backspace  
> > correctly reverts to text mode.  I then tried Xorg -configure to look for 
> > hints to improve resolution; however, that resulted in a segfault almost 
> > immediately.
> >
> 
> I'm pretty sure
> 
> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
> 
> is not supported in the sense of working as opposed to being
> recognized. i.e. 1024x768 is likely as good as it gets until support
> is added. Even 4400 is problematic at the moment.
> 
> But I'm willing to be corrected by people more in the know. :-)

Haswell graphics should work since a few months now.

X segfaulting at a low address normally means the framebuffer
could not be mmap'd due to the /dev/drm* permissions not
being set correctly.

Re: Does OpenBSD's wpa_supplicant support PSK?

[Frank Brodbeck]

On Tue, Feb 11, 2014 at 06:10:01PM +, Stuart Henderson wrote:
> If you need this right at boot time, you'll need to run wpa_supplicant
> from the hostname.rum0 file (adding a line "!/etc/rc.d/wpa_supplicant start"
> may possibly work, but this is not tested). Though dhclient will hang around
> in the background if it's unable to obtain an IP address at startup.

I am using wpa-supplicant with wired 802.1X at work and I do start it
from hostname.if(5). But keep in mind that this means that you've got to
store your password in cleartext somewhere on your disk. This is the one
and only case I see the need for a network manager who's capable of
talking to some sort of keyring like gnome does it.

Frank.

Re: Starting cupsd by rc.d

[Antoine Jacoutot]

> Obviously cupsd is running as 'root' as it has been started by
> rc.local. If I remember right it used to be user '_cups' who exists:

Run the rc.d script in debug mode (i.e. -d) and you should be able to see the 
output.

-- 
Antoine

Re: Starting cupsd by rc.d

[Stefan Wollny]

Am Tue, 11 Feb 2014 13:39:42 -0800
schrieb Philip Guenther :

> On Tue, Feb 11, 2014 at 1:14 PM,   wrote:
> > I have a strange behaviour of starting cupsd via rc.d-system:
> >
> > For a long time I use ~current on my old Lenovo T60:
> > OpenBSD 5.5-beta (GENERIC.MP) #233: Fri Feb  7 12:14:13 MST 2014
> > t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> > (full dmesg at the end)
> 
> You're keeping current with the kernel; you're keeping the base and
> packages up to date too?  "pkg_add -u" is your friend!
> 
> 
> > Since a few month cupsd won't start by the rc.d-system.
> 
> So you waited a few months to make it...harder to track down and less
> likely to be fixed before the 5.5 release?  A few months ago was the
> update to cups 1.7.0 and there have been 6 changes to just the
> Makefile since then...
> 
> 
> > I have the
> > following line in my rc.conf.local:
> >  $ cat /etc/rc.conf.local | grep cups
> > pkg_scripts="adsuck clamd freshclam dbus_daemon avahi_daemon cupsd"
> ...
> > Well as you might already guess - cupsd won't start. The log-line
> > reads quote "cupsd (failed)"
> 
> That's just the console output.  Does it write anything to the logs
> under /var/logs/ ?
> 
> 
> Philip Guenther
> 

One more info on my setup:

I start OpenBSD usually with /usr mounted read-only (and /var with
noexec). While this would certainly be a nuisance for developers, for
a production system this gives a little more protection - right? (Just
another part of the safety-puzzle...)

Does for any reason cups require /usr to be mounted read-write if
started by rd.d-system? Seems to be rather unlikely but I didn't want
to hide that piece of information.

STEFAN 

Re: Starting cupsd by rc.d

[Stefan Wollny]

Am Tue, 11 Feb 2014 13:39:42 -0800
schrieb Philip Guenther :

> On Tue, Feb 11, 2014 at 1:14 PM,   wrote:
> > I have a strange behaviour of starting cupsd via rc.d-system:
> >
> > For a long time I use ~current on my old Lenovo T60:
> > OpenBSD 5.5-beta (GENERIC.MP) #233: Fri Feb  7 12:14:13 MST 2014
> > t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> > (full dmesg at the end)
> 
> You're keeping current with the kernel; you're keeping the base and
> packages up to date too?  "pkg_add -u" is your friend!
> 
> 
> > Since a few month cupsd won't start by the rc.d-system.
> 
> So you waited a few months to make it...harder to track down and less
> likely to be fixed before the 5.5 release?  A few months ago was the
> update to cups 1.7.0 and there have been 6 changes to just the
> Makefile since then...
> 
> 
> > I have the
> > following line in my rc.conf.local:
> >  $ cat /etc/rc.conf.local | grep cups
> > pkg_scripts="adsuck clamd freshclam dbus_daemon avahi_daemon cupsd"
> ...
> > Well as you might already guess - cupsd won't start. The log-line
> > reads quote "cupsd (failed)"
> 
> That's just the console output.  Does it write anything to the logs
> under /var/logs/ ?
> 
> 
> Philip Guenther
> 

Hi Philip,

thank's a lot for your quick reply.

Well: Yes, of course, I run at least once a week the
following as a script:
~
#!/bin/sh
#
cd /tmp
sudo mount -u -w /usr
sudo pkg_add -ui
cd /usr/src
sudo cvs -qd anon...@openbsd.cs.fau.de:/cvs up -Pd
cd /usr/xenocara
sudo cvs -qd anon...@openbsd.cs.fau.de:/cvs up -Pd
cd /usr/ports
sudo cvs -qd anon...@openbsd.cs.fau.de:/cvs up -Pd
sudo mount -u -r /usr
cd ~/
~

Please have a second look at my original post: I quoted the output of
$ pkg_info | grep cups
cups-1.7.1p0Common Unix Printing System
cups-filters-1.0.44 OpenPrinting CUPS filters
cups-libs-1.7.1 CUPS libraries and headers
cups-pdf-2.6.1p0PDF backend for CUPS
hpcups-3.14.1   HP native CUPS driver

Shouldn't this be the latest version?

Beside this: Why does cups start by /etc/rc.local but not
by /etc/rd.d/cupsd???

Additional info:
~
$ ls -alh /etc/rc.d/cups*
-r-xr-xr-x  1 root  bin   177B Feb  5 09:49 /etc/rc.d/cups_browsed
-r-xr-xr-x  1 root  bin   1.5K Feb  4 15:02 /etc/rc.d/cupsd
~

Does this make sense???

Again: Thank you for your thoughts!

Cheers,
STEFAN

Re: Can't ping CARP interface from CARP master box.

[andy]

Hi,

You should be able to ping the CARP IP addresses from any host (including
the master), so something is wrong here.

This can sometimes be due to a routing problem.

Your routing table should look similar to;

10.0.0.1 10.0.0.1 UH 04 - 4 carp0
10.0.0.2 127.0.0.1  UGHS   02 33144 8 lo0  
10.0.0.2/32  10.0.0.2 U  00 - 4 carp0
10.0.0.3 127.0.0.1  UGHS   02 33144 8 lo0  
10.0.0.3/32  10.0.0.3 U  00 - 4 carp0

Here 10.0.0.1 is the primary IP, and 10.0.0.2 and 10.0.0.3 are secondary
carp IPs.

Your /etc/hostname.carp file should look like;

inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 pass carpsecurehashpasswd
advbase 1 advskew 0
inet alias 10.0.0.2 255.255.255.255
inet alias 10.0.0.3 255.255.255.255

Notice the secondary IP's have a /32 subnet (which is correct despite the
spurious errors in dmesg during carp fail-overs).

It is having the /32 subnet on the secondaries which causes the creation
of the additional route entry to lo0.

What does your routing table and carp look like?

Cheers, Andy.


On Tue, 11 Feb 2014 16:50:08 -0500, John Jasen 
wrote:
> I can't remember specifically where I read it, but I recall specific
> warnings somewhere in the CARP documentation about ping and the virtual
IP.
> 
> I encountered similar oddities configuring CARP for IPv4 and IPv6. You
> may want to look at your route tables.
> 
> On 02/11/2014 04:41 PM, Laurent CARON wrote:
>> Hi,
>> 
>> Any clue about this issue ?
>> 
>> Thanks
>> 
>> On Fri, Jan 31, 2014 at 06:13:15PM +0100, Laurent CARON wrote:
>>> Hi,
>>>
>>> I'm currently experiencing what I would call a strange behavior (maybe
a
>>> total config fuck up on my side, who knows...).
>>>
>>> I'm basically having 2 boxes acting as a CARP gateway for my servers.
>> 
>> ...snip...
>> 
>>> Problem: I can ping 46.21.116.5 either from the outside world or my
>>> inside machines (even the machine not in carp master state), but not
>>> from the carp master machine.
>> 
> 
> 
> -- 
> -- John Jasen (jja...@realityfailure.org)
> -- No one will sorrow for me when I die, because those who would
> -- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

Re: Can't ping CARP interface from CARP master box.

[John Jasen]

I can't remember specifically where I read it, but I recall specific
warnings somewhere in the CARP documentation about ping and the virtual IP.

I encountered similar oddities configuring CARP for IPv4 and IPv6. You
may want to look at your route tables.

On 02/11/2014 04:41 PM, Laurent CARON wrote:
> Hi,
> 
> Any clue about this issue ?
> 
> Thanks
> 
> On Fri, Jan 31, 2014 at 06:13:15PM +0100, Laurent CARON wrote:
>> Hi,
>>
>> I'm currently experiencing what I would call a strange behavior (maybe a
>> total config fuck up on my side, who knows...).
>>
>> I'm basically having 2 boxes acting as a CARP gateway for my servers.
> 
> ...snip...
> 
>> Problem: I can ping 46.21.116.5 either from the outside world or my
>> inside machines (even the machine not in carp master state), but not
>> from the carp master machine.
> 


-- 
-- John Jasen (jja...@realityfailure.org)
-- No one will sorrow for me when I die, because those who would
-- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

Re: Can't ping CARP interface from CARP master box.

[Laurent CARON]

Hi,

Any clue about this issue ?

Thanks

On Fri, Jan 31, 2014 at 06:13:15PM +0100, Laurent CARON wrote:
> Hi,
> 
> I'm currently experiencing what I would call a strange behavior (maybe a
> total config fuck up on my side, who knows...).
> 
> I'm basically having 2 boxes acting as a CARP gateway for my servers.

...snip...

> Problem: I can ping 46.21.116.5 either from the outside world or my
> inside machines (even the machine not in carp master state), but not
> from the carp master machine.

Re: Starting cupsd by rc.d

[Philip Guenther]

On Tue, Feb 11, 2014 at 1:14 PM,   wrote:
> I have a strange behaviour of starting cupsd via rc.d-system:
>
> For a long time I use ~current on my old Lenovo T60:
> OpenBSD 5.5-beta (GENERIC.MP) #233: Fri Feb  7 12:14:13 MST 2014
> t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> (full dmesg at the end)

You're keeping current with the kernel; you're keeping the base and
packages up to date too?  "pkg_add -u" is your friend!


> Since a few month cupsd won't start by the rc.d-system.

So you waited a few months to make it...harder to track down and less
likely to be fixed before the 5.5 release?  A few months ago was the
update to cups 1.7.0 and there have been 6 changes to just the
Makefile since then...


> I have the
> following line in my rc.conf.local:
>  $ cat /etc/rc.conf.local | grep cups
> pkg_scripts="adsuck clamd freshclam dbus_daemon avahi_daemon cupsd"
...
> Well as you might already guess - cupsd won't start. The log-line reads
> quote "cupsd (failed)"

That's just the console output.  Does it write anything to the logs
under /var/logs/ ?


Philip Guenther

Starting cupsd by rc.d

[stefan . wollny]

Hi there!

I have a strange behaviour of starting cupsd via rc.d-system:

For a long time I use ~current on my old Lenovo T60:
OpenBSD 5.5-beta (GENERIC.MP) #233: Fri Feb  7 12:14:13 MST 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
(full dmesg at the end)

Since a few month cupsd won't start by the rc.d-system. I have the
following line in my rc.conf.local:
 $ cat /etc/rc.conf.local | grep cups
pkg_scripts="adsuck clamd freshclam dbus_daemon avahi_daemon cupsd"

(As a side-note to a recent thread: I have _always_ simply copied
rc.conf to rc.conf.local and just adjusted one line by prepending a '#'
- I learned now that this is not the way it is supposed to be done, but
'just works'...)

Well as you might already guess - cupsd won't start. The log-line reads 
quote "cupsd (failed)"

Now the interessting part is that cupsd actually does start if I do it
the old way via rc.local:

# cupsd
if [ -x /usr/local/sbin/cupsd ]; then
echo -n ' cupsd'; /usr/local/sbin/cupsd
fi

$ top
< ... >
6 root   2  0 1936K 4556K idle   kqread0:00  0.00%   cupsd
< ... >

Obviously cupsd is running as 'root' as it has been started by
rc.local. If I remember right it used to be user '_cups' who exists:

$ cat /etc/group | grep
cup 
 
bin:*:7:_cups
_cups:*:541:

Cups has been installed from packages:
$ pkg_info | grep cups
cups-1.7.1p0Common Unix Printing System
cups-filters-1.0.44 OpenPrinting CUPS filters
cups-libs-1.7.1 CUPS libraries and headers
cups-pdf-2.6.1p0PDF backend for CUPS
hpcups-3.14.1   HP native CUPS driver

$ ls -alh /usr/local/sbin/cups*
-r-xr-xr-x  1 root bin47.7K Feb  5
09:49 /usr/local/sbin/cups-browsed 
-r-xr-xr-x  1 root bin10.0K Feb
4 15:02 /usr/local/sbin/cupsaccept 
-r-xr-xr-x  1 root bin10.2K Feb
4 15:02 /usr/local/sbin/cupsaddsmb -
r-xr-xr-x  1 root bin10.6K Feb
4 15:02 /usr/local/sbin/cupsctl 
-r-x--  1 root bin 431K Feb  4 15:02 /usr/local/sbin/cupsd 
lrwxr-xr-x  1 root wheel10B Feb  8
02:58 /usr/local/sbin/cupsdisable -> cupsaccept 
lrwxr-xr-x  1 root wheel10B Feb  8 02:58 /usr/local/sbin/cupsenable
-> cupsaccept 
-r-xr-xr-x  1 root bin27.3K Feb  4 15:02 /usr/local/sbin/cupsfilter 
lrwxr-xr-x  1 root wheel10B Feb  8 02:58 /usr/local/sbin/cupsreject
-> cupsaccept

And yes: I have been running "cupsenable" (and additionally
"cupsaccept" ... )

Anyone a clue why cups won't start by rc.d? Any additional info needed?

Thanks in advance for any help!

Cheers,
STEFAN


OpenBSD 5.5-beta (GENERIC.MP) #233: Fri Feb  7 12:14:13 MST 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel"
686-class) 1.83 GHz cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
real mem  = 3219484672 (3070MB) avail mem = 3154972672 (3008MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/27/09, BIOS32 rev. 0 @
0xfd6b0, SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO
version "79ETE5WW (2.25 )" date 08/27/2009 bios0: LENOVO 200855G
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT
SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3)
EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3)
USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at
acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel"
686-class) 1.83 GHz cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0:
misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr
0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "92P1139" serial  6480 type LION oem
"Panasonic" acpi

Re: Does OpenBSD's wpa_supplicant support PSK?

[Stuart Henderson]

On 2014-02-10, Zbigniew  wrote:
> Hi! I'm unable to access my WiFi router. The problem is, that every
> attempt to register by using wpa_supplicant is refused:

Various replies already, but here's a simple one for the benefit of the
list archives:

wpa_supplicant has only minimal support for wireless on OpenBSD, just
enough for connecting to WPA Enterprise networks (and it also works for wired
802.1x).

This is different to other OS, where it is used as a multi-purpose program
for connecting to WEP/WPA PSK networks, choosing credentials based on SSID,
scanning for networks, etc..

> One more question: assuming, that with a little help I'll make it
> work, I'll need it to make it run _before_ the system reads
> /etc/hostname.rum0, where there is dhclient invocation; so how can I
> execute /etc/rc.d/wpa_supplicant _earlier_ during system boot-up
> sequence?

If you need this right at boot time, you'll need to run wpa_supplicant
from the hostname.rum0 file (adding a line "!/etc/rc.d/wpa_supplicant start"
may possibly work, but this is not tested). Though dhclient will hang around
in the background if it's unable to obtain an IP address at startup.

Re: macppc man on amd64

[Christian Weisgerber]

On 2014-02-11, Jan Stary  wrote:

> On my current/amd64 install, some manpages get installed under
> /usr/share/man/man8/macppc/ - is that intentional?

Yes.  All man pages are installed on all archs.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: macppc man on amd64

[Theo de Raadt]

>On my current/amd64 install, some manpages get installed under
>/usr/share/man/man8/macppc/ - is that intentional?

Yes.

Re: Encrypted filesystem fscking -- 'fsck -c 2' using fsck from before release 5.0?

[Philip Guenther]

On Mon, Feb 10, 2014 at 2:38 PM, Damon Getsman  wrote:
> I have been able to mount the filesystem read-only.  I'm not sure what else
> to do at this point.  I feel like I'm overlooking something really obvious
> and foolish, but I can't quite put my finger on it.  Anybody have any other
> ideas?

You have a filesystem that has been significantly corrupted by a crash
in a way that 'should not be possible' but you've managed to mount it
read-only and can access the data?

Personally, at that point, I would not completely trust any procedure
that claimed to recover from that except newfs and restoring the data.
 It's a PITA, but something you can actually have confidence in.


Philip Guenther

Re: Encrypted filesystem fscking -- 'fsck -c 2' using fsck from before release 5.0?

[Damon Getsman]

Thank you for the quick reply, Otto.  I overlooked that option, which is
kind of funny, I know it's saved my butt before.  Anyway, I tried using
alternate superblocks, several of them (picked at random from various spots
within the ones named by newfs -N), and fsck is still dying with the same
error message.

I have been able to mount the filesystem read-only.  I'm not sure what else
to do at this point.  I feel like I'm overlooking something really obvious
and foolish, but I can't quite put my finger on it.  Anybody have any other
ideas?


On Mon, Feb 10, 2014 at 7:38 AM, Otto Moerbeek  wrote:
>
>  > I have an OpenBSD Virtual Machine (v.5.4) that, unfortunately, got shut
> > down improperly the other day.  This machine had a mounted partition
> > /dev/rwd0j, which disklabel is reporting as a fstype of 4.2BSD (fsize
> 2048,
> > bsize 16384, cgp 1).  The partition is completely full with an encrypted
> > filesystem image, which was mounted at the time of the evil shutdown.
>  When
> > I try to mount the (host [/dev/rwd0j]) partition, I receive an error
> > telling me that the filesystem is not clean and I need to run fsck.
>  When I
> > manually run fsck, I am receiving an error that the 'version of
> filesystem
> > is too old', and that I must update it to a more recent format with 'fsck
> > -c 2', using a version of fsck that is from before release 5.0.
>


>  > Unfortunately, I have vital services on this virtual machine that I
> need to
> > get running again as soon as possible for users other than myself.  I
> have
> > not been able to locate any archive with a binary version of fsck for
> i386
> > from a release of OpenBSD prior to 5.0, nor am I able to find any way
> > around this, at least during the first few dozen times ramming my head
> into
> > the brick wall here.  I would very much appreciate any ideas that anybody
> > might have in order to get this filesystem clean and running again asap.
>


>  Likely you superblock is corrupted, giving a spurious error message
> concerning the fs version.
>
> Try using an alternate superblock, using the -b option (see man page).

macppc man on amd64

[Jan Stary]

On my current/amd64 install, some manpages get installed under
/usr/share/man/man8/macppc/ - is that intentional?

Jan

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[Brad Smith]

On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote:
> On 10 February 2014 13:11, RD Thrush  wrote:
> > With a somewhat recent i7 desktop, using startx, X seems to run ok; 
> > however, at 1024x768 rather than the expected 1920x1200 resolution. 
> > ctl-alt-keypad+ or - have no effect on resolution.  ctl-alt-backspace  
> > correctly reverts to text mode.  I then tried Xorg -configure to look for 
> > hints to improve resolution; however, that resulted in a segfault almost 
> > immediately.
> >
> 
> I'm pretty sure
> 
> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
> 
> is not supported in the sense of working as opposed to being
> recognized. i.e. 1024x768 is likely as good as it gets until support
> is added. Even 4400 is problematic at the moment.
> 
> But I'm willing to be corrected by people more in the know. :-)
> 
>  Ken

4400 works fine for me.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

On 02/10/14 13:20, Kenneth Westerback wrote:
> On 10 February 2014 13:11, RD Thrush  wrote:
>> With a somewhat recent i7 desktop, using startx, X seems to run ok; however, 
>> at 1024x768 rather than the expected 1920x1200 resolution. ctl-alt-keypad+ 
>> or - have no effect on resolution.  ctl-alt-backspace  correctly reverts to 
>> text mode.  I then tried Xorg -configure to look for hints to improve 
>> resolution; however, that resulted in a segfault almost immediately.
>>
> 
> I'm pretty sure
> 
> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
> 
> is not supported in the sense of working as opposed to being
> recognized. i.e. 1024x768 is likely as good as it gets until support
> is added. Even 4400 is problematic at the moment.
> 
> But I'm willing to be corrected by people more in the know. :-)
> 
>  Ken

Thanks for the feedback.  Apparently, Intel HD Graphics 4000 is similarly not 
yet supported...

An older (~Nov 2012) i7 system has similar behavior, ie. vesa @1024x768 and 
segfault w/ Xorg -configure.

I have appended dmesg, Xorg.0.log for segfault as well as for vesa startx.


 dmesg #
OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb  7 11:45:09 MST 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17051402240 (16261MB)
avail mem = 16589279232 (15820MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba40 (112 entries)
bios0: vendor American Megatrends Inc. version "1204" date 11/26/2013
bios0: ASUSTeK COMPUTER INC. P8Q77-M
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT ASF! SSDT SSDT DMAR
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) P0P1(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) 
PXSX(S4) RP06(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.43 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 MHz
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application process

Re: PHP SIGSEGV with Mediawiki

[Cyrus]

On 02/11/2014 03:52 AM, Fred wrote:
> On 02/10/14 16:36, Fred wrote:
>> On 02/10/14 14:47, Cyrus wrote:
>>> I never got a reply to this. I am still having issues with PHP crashing,
>>> in fact it seems to be happening for every new user. Old sites are
>>> working fine. I don't know why this is happening, as before there is
>>> very little information in /var/log/php-fpm.log about the crash. I need
>>> information on how to get more details from the system.
>>>
>>
>> kdump(1) might help you solve this issue.
>>
>> hth
>>
>> Fred
>>
> /kdump/ktrace/ using kdump to inspect the file created by ktrace...
> 
> 

Thanks.

Well here is what kdump says happens when the index.php from Wordpress
is ran and PHP segfaults. I should probably submit this as a bug, but
I've never done that before. I'm not really sure if I'm the bug. Other
scripts, including wordpress run fine for other users. It seems to be
the latest users that can't run any scripts.

  8368 php-fpm-5.3 EMUL  "native"
  8368 php-fpm-5.3 STRU  struct sockaddr { AF_INET, 127.0.0.1:11108 }
  8368 php-fpm-5.3 RET   accept 3
  8368 php-fpm-5.3 CALL  clock_gettime(CLOCK_MONOTONIC,0x7f7d44a0)
  8368 php-fpm-5.3 STRU  struct timespec { 86638.942214588 }
  8368 php-fpm-5.3 RET   clock_gettime 0
  8368 php-fpm-5.3 CALL  gettimeofday(0x7f7d44a0,0)
  8368 php-fpm-5.3 STRU  struct timeval { 1392129901.926910 }
  8368 php-fpm-5.3 RET   gettimeofday 0
  8368 php-fpm-5.3 CALL  getrusage(RUSAGE_SELF,0x7f7d4400)
  8368 php-fpm-5.3 RET   getrusage 0
  8368 php-fpm-5.3 CALL  getrusage(RUSAGE_CHILDREN,0x7f7d4400)
  8368 php-fpm-5.3 RET   getrusage 0
  8368 php-fpm-5.3 CALL  gettimeofday(0x7f7d4490,0)
  8368 php-fpm-5.3 STRU  struct timeval { 1392129901.927026 }
  8368 php-fpm-5.3 RET   gettimeofday 0
  8368 php-fpm-5.3 CALL  poll(0x7f7d4590,0x1,0x1388)
  8368 php-fpm-5.3 RET   poll 1
  8368 php-fpm-5.3 CALL  read(0x3,0x7f7d4590,0x8)
  8368 php-fpm-5.3 GIO   fd 3 read 8 bytes
   "\^A\^A\0\^A\0\b\0\0"
  8368 php-fpm-5.3 RET   read 8
  8368 php-fpm-5.3 CALL  read(0x3,0x7f7d45a0,0x8)
  8368 php-fpm-5.3 GIO   fd 3 read 8 bytes
   "\0\^A\0\0\0\0\0\0"
  8368 php-fpm-5.3 RET   read 8
  8368 php-fpm-5.3 CALL  read(0x3,0x7f7d4590,0x8)
  8368 php-fpm-5.3 GIO   fd 3 read 8 bytes

   "\^A\^D\0\^A\^C*\^F\0"

  8368 php-fpm-5.3 RET   read 8

  8368 php-fpm-5.3 CALL  read(0x3,0x7f7d45a0,0x330)

  8368 php-fpm-5.3 GIO   fd 3 read 816 bytes


"\^O#SCRIPT_FILENAME/var/www/sites/kval-nyhet/index.php\f\0QUERY_STRING\^N\^CREQUEST_METHODGET\f\0CONT\

ENT_TYPE\^N\0CONTENT_LENGTH


PATH_INFO/index.php\f\0QUERY_STRING\^N\^CREQUEST_METHODGET\f\0CONTENT_TYPE\^N\0CONTENT_LENGTH\v

SCRIPT_NAME/index.php\v\^AREQUEST_URI/\f


DOCUMENT_URI/index.php\r\^QDOCUMENT_ROOT/sites/kval-nyhet\^O\bSERVER_PROTOCOLHTTP/1.1\^Q\aGATEWAY_INT\


ERFACECGI/1.1\^O\vSERVER_SOFTWAREnginx/1.4.1\v\vREMOTE_ADDR192.168.0.3\v\^EREMOTE_PORT51449\v\vSERVER\


_ADDR192.168.0.2\v\^BSERVER_PORT80\v\^VSERVER_NAMEnyhethvbvg5gg66o.onion\^O\^CREDIRECT_STATUS200\

\^VHTTP_HOSTnyhethvbvg5gg66o.onion\^ODHTTP_USER_AGENTMozilla/5.0 (X11;
Linux x86_64; rv:27.0)\
 Gecko/20100101
Firefox/27.0\v?HTTP_ACCEPTtext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q\

=0.8\^T\^NHTTP_ACCEPT_LANGUAGEen-US,en;q=0.5\^T\rHTTP_ACCEPT_ENCODINGgzip,
deflate\b\^AHTTP_DNT1\^O
HTTP_CONNECTIONkeep-alive\0\0\0\0\0\0"
  8368 php-fpm-5.3 RET   read 816/0x330
  8368 php-fpm-5.3 CALL  read(0x3,0x7f7d4590,0x8)
  8368 php-fpm-5.3 GIO   fd 3 read 8 bytes
   "\^A\^D\0\^A\0\0\0\0"
  8368 php-fpm-5.3 RET   read 8
  8368 php-fpm-5.3 CALL  gettimeofday(0x7f7e3b90,0)
  8368 php-fpm-5.3 STRU  struct timeval { 1392129901.927553 }
  8368 php-fpm-5.3 RET   gettimeofday 0
  8368 php-fpm-5.3 CALL  lstat(0x7f7e3d60,0x7f7e3c40)
  8368 php-fpm-5.3 NAMI  "/var/www/sites/kval-nyhet/index.php"
  8368 php-fpm-5.3 STRU  struct stat { dev=0, ino=11752572,
mode=-rw-r--r-- , nlink=1, uid=1042, gid=67, rdev=46973975,
atime=1392043543.479328112, mtime=1392042019.844487152,
ctime=1392042019.844487152, size=418, blocks=8, blksize=32768,
flags=0x0, gen=0x0 }
  8368 php-fpm-5.3 RET   lstat 0
  8368 php-fpm-5.3 CALL  lstat(0x7f7e3d60,0x7f7e3a90)
  8368 php-fpm-5.3 NAMI  "/var/www/sites/kval-nyhet"
  8368 php-fpm-5.3 STRU  struct stat { dev=0, ino=11754053,
mode=drwxrwxrwx , nlink=6, uid=1042, gid=67, rdev=46975478,
atime=1392082242.859385387, mtime=1392042028.289330592,
ctime=1392042824.605197430, size=1024, blocks=8, blksize=32768,
flags=0x0, gen=0x0 }
  8368 php-fpm-5.3 RET   lstat 0
  8368 php-fpm-5.3 CALL  lstat(0x7f7e3d60,0x7f7e38f0)
  8368 php-fpm-5.3 NAMI  "/var/www/sites"
  8368 php-fpm-5.3 STRU  struct stat { dev=0, ino=10862592,
mode=drwxr-xr-x , nlink=70, uid=0, gid=1, rdev=43406472,
atime=1392129604.122584194, mtime=1392042776.585950910,
ctime=1392042776.585950910, size=1536, blocks=8, blksize=32768,
flags=0x0, gen=0x0 }
  8368 php-fpm-5.3 RET   lstat 0
  8368 php-fpm-5

Re: Yaifo WIP

[Jiri B]

On Tue, Feb 11, 2014 at 11:07:08AM +, Jona Joachim wrote:
> On 2014-02-09, Stuart Henderson  wrote:
> > On 2014-02-08, Jona Joachim  wrote:
> >> Hello,
> >> I've been in need for yaifo for quite some time now, so I decided to 
> >> bring up some patches to make it work with -CURRENT.
> >
> > Seems like a good time to ask: with the new autoinstall(8) functionality,
> > do you still need yaifo?
> >
> > Are there any small changes to the auto installer that would help the
> > standard installer replace yaifo in more situations?
> 
> I think yaifo is very useful for situations where the machine is in some
> datacenter where you do not control the network infrastructure and don't
> have local access. In this case, you do not control the dhcp server (if
> there is one) and autoinstall cannot work. If autoinstall had the option
> to read the config files from the local hard drive this could be
> addressed. One of the advantages of yaifo is also that you can see in
> real-time if things go wrong during the upgrade and correct the errors
> (broken mirrors, changes to devices, etc.) autoinstall is definitely a
> great feature, I haven't tried it out so far.
> 
> Best regards,
> Jona

Well auto-install would read /install.conf from '/' sitting in
the ramdisk, it would be enough.

Yes, one would need to build own ramdisk to have such file,
then I think would be the same (I just guess - to inject
own mbr with boot loading this ramdisk).

In any case, reading /install.conf from '/' inside ramdisk
would be great. I can just imagine one could send an usb
stick for initial deployment to a client/customer, of just
send him an url for raw image which could be deployed to disk.
The latter configuration would be just done remotely or via
a configuration manager...

jirib

Re: calendar.birthday - fathers of full-beard look (Marx, Engels)

[Jason McIntyre]

On Tue, Feb 11, 2014 at 09:11:27AM +0100, Martin Schr?der wrote:
> 2014-02-10 22:04 GMT+01:00 Jiri B :
> >  11/26  Norbert Weiner born, 1894
> 
> s/Weiner/Wiener/
> 
> Check also March 18th.
> 
> Best
>Martin
> 

right, done. but diff next time, please.
jmc

Re: Yaifo WIP

[Jona Joachim]

On 2014-02-09, Stuart Henderson  wrote:
> On 2014-02-08, Jona Joachim  wrote:
>> Hello,
>> I've been in need for yaifo for quite some time now, so I decided to 
>> bring up some patches to make it work with -CURRENT.
>
> Seems like a good time to ask: with the new autoinstall(8) functionality,
> do you still need yaifo?
>
> Are there any small changes to the auto installer that would help the
> standard installer replace yaifo in more situations?

I think yaifo is very useful for situations where the machine is in some
datacenter where you do not control the network infrastructure and don't
have local access. In this case, you do not control the dhcp server (if
there is one) and autoinstall cannot work. If autoinstall had the option
to read the config files from the local hard drive this could be
addressed. One of the advantages of yaifo is also that you can see in
real-time if things go wrong during the upgrade and correct the errors
(broken mirrors, changes to devices, etc.) autoinstall is definitely a
great feature, I haven't tried it out so far.

Best regards,
Jona

Re: openvpn in rdomain hangs

[antoine]

Chris Cappuccio  nmedia.net> writes:

> 
> Giancarlo Razzolini [grazzolini  gmail.com] wrote:
> > I've used rdomains, but not for this. In this case I would use mpath and
> > pf only. I really do not see the need for using rdomains in this case.
> > It introduces too much complexity for a simple thing.
> > 
> 
> That's nice. But what about the problem?
> 
> 

Hi,

Did you find a solution  as I have the same issue ?

Thanks

Re: calendar.birthday - fathers of full-beard look (Marx, Engels)

[Martin Schröder]

2014-02-10 22:04 GMT+01:00 Jiri B :
>  11/26  Norbert Weiner born, 1894

s/Weiner/Wiener/

Check also March 18th.

Best
   Martin

Re: calendar.birthday - fathers of full-beard look (Marx, Engels)

[Jason McIntyre]

On Mon, Feb 10, 2014 at 04:04:58PM -0500, Jiri B wrote:
> I saw some calendar.birthday diff, so what about this one? :)
> 

added (engels, as opposed to engles).
jmc

> Index: calendar.birthday
> ===
> RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.birthday,v
> retrieving revision 1.55
> diff -u -p -r1.55 calendar.birthday
> --- calendar.birthday 29 Dec 2013 18:44:43 -  1.55
> +++ calendar.birthday 10 Feb 2014 21:02:15 -
> @@ -110,6 +110,7 @@
>  03/14Casey Jones born, 1864
>  03/14Giovanni Virginio Schiaparelli born, 1835, astronomer;
>   named Mars "canals"
> +03/14Karl Marx died, 1883
>  03/15Julius Caesar assassinated by Brutus; Ides of March, 44BC
>  03/15J.J. Robert's Birthday in Liberia
>  03/16George Clymer born, 1739
> @@ -165,6 +166,7 @@
>  05/01Little Walter (Marion Walter Jacobs) is born in Alexandria,
>   Louisiana, 1930
>  05/02Dr. Benjamin Spock born, 1903
> +05/05Karl Marx born, 1818
>  05/09Pinza died, 1957
>  05/10Fred Astaire (Frederick Austerlitz) born in Omaha, Nebraska, 
> 1899
>  05/11Douglas Adams dies in Santa Barbara, 2001
> @@ -225,6 +227,7 @@
>   Lawrence KS, 1997
>  08/02Fela Kuti dies of AIDS-related heart failure in Lagos Nigeria, 
> 1997
>  08/03Lenny Bruce dies of a morphine overdose, 1966
> +08/05Friedrich Engels died, 1895
>  08/06Edsger Wybe Dijkstra died after a long struggle with cancer, 
> 2002
>  08/08Dustin Hoffman born in Los Angeles, 1937
>  08/12Thomas Mann's Death, 1955
> @@ -319,6 +322,7 @@
>  11/26Charles Schulz born in Minneapolis, 1922
>  11/26Norbert Weiner born, 1894
>  11/27Bruce Lee born in San Francisco, 1940
> +11/28Friedrich Engles born, 1820
>  11/29John Mayall is born in Cheshire, England, 1933
>  11/30Cleopatra died, 30 BC
>  11/30Mark Twain (Samuel Clemens) born in Florida, Missouri, 1835

Re: calendar - Robert Morris

[Jason McIntyre]

On Mon, Feb 10, 2014 at 04:10:56PM +0100, Jan Stary wrote:
> The following diff adds Robert Morris
> of the original Bell Labs group to the calendar.
> 
>   Jan
> 

added.
jmc

> 
> --- calendar.birthday.origMon Feb 10 16:07:38 2014
> +++ calendar.birthday Mon Feb 10 16:08:57 2014
> @@ -200,6 +200,7 @@
>  06/23Alan Mathison Turing born, Paddington, London, 1912
>  06/25Eric Arthur Blair (a.k.a. George Orwell) born, 1903
>  06/26William Thomson (a.k.a. Lord Kelvin) born, 1824
> +06/26Robert Morris dies, 2011
>  06/27Helen Keller born, 1880
>  07/03Franz Kafka born in Vienna, 1883
>  07/04Nathaniel Hawthorne born in Salem, Massachusetts, 1804
> @@ -215,6 +216,7 @@
>   Saint Nicholas"
>  07/18Brian Auger is born in London, 1939
>  07/20Bruce Lee died in Hong Kong, 1973
> +07/25Robert Morris is born in Boston, 1932
>  07/25Steve Goodman is born in Chicago, 1948
>  07/28(Helen) Beatrix Potter born, 1866
>  07/29Mussolini born, 1883