Re: mysql.sock location

2013-08-23 Thread Guy Ferguson

Gilbert,

Thanks very much for supplying the text of your readme.

In mine, v5.1.68, which I am pretty sure was the latest version on i386 
about tow weeks ago, all the text beginning with the heading


chrooted daemons and MySQL socket
 =

...does not exist.

SO thanks for that. And I agree with your point about multiple readings. 
I guess I've learnt bad habits of googling and skimming for quick tuutes 
on how to do things, with OpenBSD I need to spend the time to learn how 
it works,


Guy

On 24/08/2013 14:46, Gilbert Sanford wrote:

chrooted daemons and MySQL socket




Re: mysql.sock location

2013-08-23 Thread Gilbert Sanford
You're welcome.  Since the OpenBSD documentation is clear and precise,
any cloud of confusion must be a product of my own defective thinking.
So I keep going back to the documentation (I stay off Google for
OpenBSD research) to push it in and push out the misunderstanding.
I always figured @misc would not be interested in hearing about my
struggles.  As far as learning is concerned, I'm just hard-headed enough
(or stubborn or persistent or tenacious or dense . . . pick one) to keep
after something until I get it.  After 5 years, I'm just now beginning
to appreciate and understand enough to recognize the genius behind
OpenBSD . . .

Gilbert

On Fri, Aug 23, 2013 at 11:53 PM, Guy Ferguson  wrote:
> Gilbert,
>
> Thanks very much for supplying the text of your readme.
>
> In mine, v5.1.68, which I am pretty sure was the latest version on i386
> about tow weeks ago, all the text beginning with the heading
>
>
> chrooted daemons and MySQL socket
>  =
>
> ...does not exist.
>
> SO thanks for that. And I agree with your point about multiple readings. I
> guess I've learnt bad habits of googling and skimming for quick tuutes on
> how to do things, with OpenBSD I need to spend the time to learn how it
> works,
>
> Guy
>
>
> On 24/08/2013 14:46, Gilbert Sanford wrote:
>>
>> chrooted daemons and MySQL socket



Re: mysql.sock location

2013-08-23 Thread Gilbert Sanford
Since you said you were new to OpenBSD, I trust the length of this
post is justified, and I'm not offending others on this list.
I've been using OpenBSD around 5 years now, but I had not subscribed
or ever posted anything to @misc until your post.  Actually, I've
never participated in any mailing list until now, so I hope my
humble attempt is helpful in some small way.  Please understand that
I trust the documentation over which the developers have spent
countless hours to make clear and precise, so I will only offer
what much wiser and knowledgeable persons (the OpenBSD developers)
have written.  Speaking again only for myself, I have learned that
in order to understand what the OpenBSD developers have so clearly
and precisely written, I must read it multiple times before I grasp
the concept well enough to achieve my objectives.  In other words,
pay very close attention to everything in the OpenBSD documentation.
Also read references to man pages if mentioned for additional insight.

I'm running -current with mysql-server-5.1.71v0 on amd64, and I am
including the README for mysql-server on MY box below.  The README
file on YOUR box may be different.  Please pay very careful attention
to the section entitled "chrooted daemons and MySQL socket" and note
that there are two things to do in order to place the MySQL socket in
the chroot:

1) Create a directory for the MySQL socket, and
2) Adjust /etc/my.cnf to put and connect to the MySQL socket within
the chroot.

See below for full context and note the author :)


$OpenBSD: README-server,v 1.7 2013/03/17 07:22:23 ajacoutot Exp $

+---
| Running mysql-server-5.1.71v0 on OpenBSD
+---

Initial setup
=

If you are installing MySQL for the first time, you have to create
a default database first. In order to create the database, please run
/usr/local/bin/mysql_install_db

You will need to tune the values in the my.cnf file (examples
available in /usr/local/share/mysql).

By default, the _mysql user, and so the MySQL processes run in the
login(1) class of "daemon". On a busy server, it may be advisable
to put the _mysql user and processes in their own login(1) class
with tuned resources, such as more open file descriptors etc.

For example, add this to the login.conf(5) file:

mysqld:\
:openfiles-cur=1024:\
:openfiles-max=2048:\
:tc=daemon:

Rebuild the login.conf.db file if necessary:

# [ -f /etc/login.conf.db ] && cap_mkdb /etc/login.conf

For larger servers and dedicated database servers, these numbers
and memory limits (e.g. datasize and stacksize) may also need to be
increased. Please report any changes and experiences to the package
maintainers so that we can update this file for future versions.

chrooted daemons and MySQL socket
=

For external program running under a chroot(8) to be able to access the
MySQL server without using a network connection, the socket must be
placed inside the chroot.

e.g. httpd(8) or nginx(8): connecting to MySQL from PHP
---
Create a directory for the MySQL socket:

# install -d -m 0711 -o _mysql -g _mysql /var/www/var/run/mysql

Adjust /etc/my.cnf to put and connect to the MySQL socket
within the chroot:

[client]
socket = /var/www/var/run/mysql/mysql.sock

[mysqld]
socket = /var/www/var/run/mysql/mysql.sock

I follow the directions above whenever I set up a new box, and I
check that mysql-server is running in the chroot after I reboot the
box.  Output from my box is below:

$ /usr/bin/sudo ls -l /var/www/var/run/mysql/
total 0
srwxrwxrwx  1 _mysql  _mysql  0 Aug 23 22:10 mysql.sock

Then I load up mysql-server.  Now that I've done this a few
thousand times, it's easy . . .

Gilbert

On Fri, Aug 23, 2013 at 10:06 PM, Guy Ferguson  wrote:
> Hmm - ok, I actually just went to that path
> (/usr/local/share/doc/pkg-readmes/) and there are 4 files, one of which is a
> mysql-server-5.x.xx..but it's only 1325  bytes, and certainly no
> comments from users like ajacoutot@. I mean, there are maybe two or three
> sugegstions about changing the login.conf and my.cnf, but it certainly
> wouldn't have been any help with the issues i faced.
>
> Perhaps there are some other dox in another location?
>
> thanks,
>
> Guy
>
> On 23/08/2013 22:16, Gilbert Sanford wrote:
>>
>> The instructions in /usr/local/share/doc/pkg-readmes/mysql-server-5.1.xx
>> have always worked for me . . . very handy reference with specific
>> instructions from ajacoutot@ on "Running mysql-server-5.1.xx on
>> OpenBSD."
>>
>> Gilbert



Re: mysql.sock location

2013-08-23 Thread Guy Ferguson
Hmm - ok, I actually just went to that path 
(/usr/local/share/doc/pkg-readmes/) and there are 4 files, one of which 
is a mysql-server-5.x.xx..but it's only 1325  bytes, and certainly 
no comments from users like ajacoutot@. I mean, there are maybe two or 
three sugegstions about changing the login.conf and my.cnf, but it 
certainly wouldn't have been any help with the issues i faced.


Perhaps there are some other dox in another location?

thanks,

Guy
On 23/08/2013 22:16, Gilbert Sanford wrote:

The instructions in /usr/local/share/doc/pkg-readmes/mysql-server-5.1.xx
have always worked for me . . . very handy reference with specific
instructions from ajacoutot@ on "Running mysql-server-5.1.xx on
OpenBSD."

Gilbert



On Fri, Aug 23, 2013 at 4:34 AM, Guy Ferguson  wrote:

liviu,
At last, I get your name right, if a little under-capitalised.  Your help
was the first step in maybe a dozen or so that got the site back up. So
thank you kindly for that.  Just some minor linking to outside the chroot
and it'll be perfect.

But thanks for the help.
guy

On 19/08/2013 02:54, Liviu Daia wrote:

On 18 August 2013, Guy Ferguson  wrote:

Livia,

  If you want to address me by name, s/Livia/Liviu/ please.  It might
not be much, but it's my name, and I kind of became attached to it over
the years. :)


Thanks for your help.

I modded the /etc/my.cnf to add in the extra "/run" directory.

A few other tweaks here and there and i can now get a test.php to
connect to the
default host mysql ($conn=mysql_connect...)

So now i'm confident that mysql is working and connectable...I just
ahve to sort out why drupal is
unhappy, which no doubt is a chroot issue.

[...]

  Like I said, the easy solution to that is to use TCP connections.
As others have pointed out, just set hostname to 127.0.0.1 in your
Drupal config, and you should be fine.

  If you insist on using UNIX sockets, you probably want to set

  socket = /var/www/run/mysql.sock

in the /etc/my.cnf, then copy /etc/my.cnf to /var/www/etc/my.cnf, and
set

  socket = /run/mysql.sock

in the client section in /var/www/etc/my.cnf.  There is no advantage in
doing things like this though, you'd be just looking for future trouble.

  Regards,

  Liviu Daia



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3211/6584 - Release Date: 08/16/13





-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3211/6603 - Release Date: 08/23/13




In some man pages Mb means MB, in others it means Mb/s

2013-08-23 Thread Zeljko Jovanovic
I was just reading some random man pages, and noticed a few places where "Mb" 
should probably be changed to "MB", since the intended meaning is Megabytes, not 
Megabits.


In the base system, these are sort(1) and ld(1). I have only a few additional 
packages installed, but found it also in /usr/local/man/cat3/pcrestack.0


The "Mb" abbreviation is also used in pf-related pages: hostapd.conf(5), 
iked.conf(5), ipsec.conf(5), pf.conf(5), in the meaning Megabits per second. So 
it could be more correctly written as Mb/s (or at least Mbps). However, since 
the Mb word, in the meaning Mb/s, is already part of pf syntax, I suppose it is 
going to stay that way. :)


Cheers,

Zeljko Jovanovic



Re: how to "aggregate" a single TCP connection, is posible?

2013-08-23 Thread Abel Abraham Camarillo Ojeda
Not yet, will test.

On Thu, Aug 22, 2013 at 7:05 AM, Stuart Henderson  wrote:
> On 2013-08-22, Abel Abraham Camarillo Ojeda  wrote:
>> Is there a way to duplicate the throughput of a single
>> TCP connection using two servers having two gigabit NICs?
>>
>> I have tried using LACP but I cannot get more than
>> 900MB of throughput...
>
> LACP uses a hash over IP addresses/vlan tags/flowlabel to avoid problems
> with out-of-order packet delivery. (Similar for equal-cost multipath).
> Have you tried a roundrobin trunk yet?



Unexpected results from boot(8) "machine memory" configuration

2013-08-23 Thread RD Thrush
I expected "machine memory =1G" to reduce the memory size of this system from 
8GB to 1GB.  After the first invocation, free memory is reduced to ~6GB.  The 
second invocation results in the expected ~1GB free memory.

My intention is to limit the size of a subsequent crash dump.  I'm surprised it 
took two invocations to get the expected results.

Thanks in advance for helping me better understand this issue.


syncing disks... done
rebooting...
>> OpenBSD/amd64 BOOT 3.23
boot> machine memory
Region 0: type 1 at 0x0 for 630KB
Region 1: type 2 at 0x9d800 for 10KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 3135984KB
Region 4: type 4 at 0xbf77c000 for 288KB
Region 5: type 3 at 0xbf7c4000 for 32KB
Region 6: type 2 at 0xbf7cc000 for 16KB
Region 7: type 4 at 0xbf7d for 16KB
Region 8: type 2 at 0xbf7d4000 for 2496KB
Region 9: type 4 at 0xbfa44000 for 28KB
Region 10: type 2 at 0xbfa4b000 for 160KB
Region 11: type 4 at 0xbfa73000 for 2060KB
Region 12: type 1 at 0xbfc76000 for 2600KB
Region 13: type 1 at 0x11000 for 4964348KB
Region 14: type 2 at 0xe000 for 262144KB
Region 15: type 2 at 0xfec0 for 4KB
Region 16: type 2 at 0xfec1 for 4KB
Region 17: type 2 at 0xfed0 for 4KB
Region 18: type 2 at 0xfed61000 for 64KB
Region 19: type 2 at 0xfed8 for 64KB
Region 20: type 2 at 0xff00 for 16384KB
Low ram: 630KB  High ram: 3135984KB
Total free memory: 8103562KB
boot> machine memory =1G
Region 0: type 1 at 0x0 for 630KB
Region 1: type 2 at 0x9d800 for 10KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 1047552KB
Region 4: type 4 at 0xbf77c000 for 288KB
Region 5: type 3 at 0xbf7c4000 for 32KB
Region 6: type 2 at 0xbf7cc000 for 16KB
Region 7: type 4 at 0xbf7d for 16KB
Region 8: type 2 at 0xbf7d4000 for 2496KB
Region 9: type 4 at 0xbfa44000 for 28KB
Region 10: type 2 at 0xbfa4b000 for 160KB
Region 11: type 4 at 0xbfa73000 for 2060KB
Region 12: type 1 at 0x11000 for 4964348KB
Region 13: type 2 at 0xe000 for 262144KB
Region 14: type 2 at 0xfec0 for 4KB
Region 15: type 2 at 0xfec1 for 4KB
Region 16: type 2 at 0xfed0 for 4KB
Region 17: type 2 at 0xfed61000 for 64KB
Region 18: type 2 at 0xfed8 for 64KB
Region 19: type 2 at 0xff00 for 16384KB
Low ram: 630KB  High ram: 3135984KB
Total free memory: 6012530KB
boot> machine memory =1G
Region 0: type 1 at 0x0 for 630KB
Region 1: type 2 at 0x9d800 for 10KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 1047552KB
Region 4: type 4 at 0xbf77c000 for 288KB
Region 5: type 3 at 0xbf7c4000 for 32KB
Region 6: type 2 at 0xbf7cc000 for 16KB
Region 7: type 4 at 0xbf7d for 16KB
Region 8: type 2 at 0xbf7d4000 for 2496KB
Region 9: type 4 at 0xbfa44000 for 28KB
Region 10: type 2 at 0xbfa4b000 for 160KB
Region 11: type 4 at 0xbfa73000 for 2060KB
Region 12: type 2 at 0xe000 for 262144KB
Region 13: type 2 at 0xfec0 for 4KB
Region 14: type 2 at 0xfec1 for 4KB
Region 15: type 2 at 0xfed0 for 4KB
Region 16: type 2 at 0xfed61000 for 64KB
Region 17: type 2 at 0xfed8 for 64KB
Region 18: type 2 at 0xff00 for 16384KB
Low ram: 630KB  High ram: 3135984KB
Total free memory: 1048182KB
boot> boot
booting hd0a:/bsd: 6503036+1639852+1076056+0+623264 [80+552312+368725]=0xe453c0
entry point at 0x10001e0 [7205c766, 3404, 24448b12, b958a304]
[ using 921888 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2013 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.4-current (GENERIC.MP) #44: Mon Aug 19 17:02:07 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1056964608 (1008MB)
avail mem = 1020780544 (973MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb0c0 (17 entries)
bios0: vendor American Megatrends Inc. version "P1.60" date 05/29/2012
bios0: ASRock A75M-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG AAFT HPET SSDT SSDT
acpi0: wakeup devices SBAZ(S4) CIR_(S3) PS2K(S4) PS2M(S4) UAR1(S4) P0PC(S4) 
GEC_(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) 
XHC0(S4) XHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A6-3500 APU with Radeon(tm) HD Graphics, 2096.45 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, packag

Re: Broken output from serial console

2013-08-23 Thread Stuart Henderson
On 2013-08-23, Hugo Osvaldo Barrera  wrote:
> On 2013-08-23 17:43, Stuart Henderson wrote:
>> On 2013-08-23, Hugo Osvaldo Barrera  wrote:
>> > When I conect my PC to the server, I see BIOS and POST output properly,
>> > I then see the OpenBSD bootloader properly, and all the kernel messages 
>> > come
>> > out fine (ie: the white-on-blue text), however, AFTER the kernel messages,
>> > I only see the following sixteen characters and nothing else (though
>> > later kernel messages like plugging in a USB are shown properly).
>> >
>> > In single user mode, this would be:
>> > "Enter pathname o"
>> >
>> > In non-single user mode, this would be
>> > "Automatic boot i"
>> >
>> > It's extremely odd. I'm cleary not having cable issues, wrong rates,
>> > or anything alike, because I'm seeing kernel output just fine.
>>
>> This is exactly what you would see if the IRQ assignment is wrong.
>> There are other possibilities too, but this is easy to check in the
>> BIOS, and is a somewhat likely problem.
>>
>> The first port (known as com0 in OpenBSD, com1 in MSDOS) should be at
>> 0x3f8 irq 4, the second should be 0x2f8 irq 3. Sometimes vendors
>> (I've seen it with Jetway) have been known to screw up and reverse
>> the irq assignments.
>
> Ah, thanks! I had checked that 0x3f8 was being used, but the irqs were
> mixed up (ie: they were swapped).
>
> Oddly I'm not seeing the first bit of the bootloader any more ("Using
> drive 0, partition 3..."), but I *am* seeing the important part which
> is the prompt for a boot commands.
>
> I'm curious though; why were kernel outputs being outputted
> properly? Shouldn't those have failed to display as well?

This may not be 100% correct but I think it's not far off (corrections
welcome): interrupts are off during the earlier printfs so the serial
port is driven in polling mode instead. When interrupts are enabled we
start sending a buffer full at once and wait for a completion interrupt,
which never comes (or at least never comes on the correct irq line).

When I first ran into this, I discovered what the problem was after
noticing that input on the *other* serial port made it start printing
more...

> > Some other OS take these from ISAPNP but OpenBSD hardcodes the
> > standard values for a PC-compatible machine and expects the port to
> > be there.

hmm, sorry, think-o: that should be s/ISAPNP/ACPI/...

> Why doesn't OpenBSD attempt to do this as well? Is there some reason to
> avoid that, or is it simply because nobody's gotten around to it?

Not really my area but my take on it is that it's overcomplicated, and
it's not going to be fully useful for the system console anyway because
we need to know at least the address of the uart well before acpi tables
are read.



Re: Broken output from serial console

2013-08-23 Thread Hugo Osvaldo Barrera
On 2013-08-23 17:43, Stuart Henderson wrote:
> On 2013-08-23, Hugo Osvaldo Barrera  wrote:
> > Hi!
> > I've started managing a serial server through a serial console, and have
> > come into some unusual issues.
> > I followed the instrucitons on faq 7.7, and also configured by BIOS
> > accordingly.
> >
> > When I conect my PC to the server, I see BIOS and POST output properly,
> > I then see the OpenBSD bootloader properly, and all the kernel messages
come
> > out fine (ie: the white-on-blue text), however, AFTER the kernel
messages,
> > I only see the following sixteen characters and nothing else (though
> > later kernel messages like plugging in a USB are shown properly).
> >
> > In single user mode, this would be:
> > "Enter pathname o"
> >
> > In non-single user mode, this would be
> > "Automatic boot i"
> >
> > It's extremely odd. I'm cleary not having cable issues, wrong rates,
> > or anything alike, because I'm seeing kernel output just fine.
>
> This is exactly what you would see if the IRQ assignment is wrong.
> There are other possibilities too, but this is easy to check in the
> BIOS, and is a somewhat likely problem.
>
> The first port (known as com0 in OpenBSD, com1 in MSDOS) should be at
> 0x3f8 irq 4, the second should be 0x2f8 irq 3. Sometimes vendors
> (I've seen it with Jetway) have been known to screw up and reverse
> the irq assignments.

Ah, thanks! I had checked that 0x3f8 was being used, but the irqs were
mixed up (ie: they were swapped).

Oddly I'm not seeing the first bit of the bootloader any more ("Using
drive 0, partition 3..."), but I *am* seeing the important part which
is the prompt for a boot commands.

I'm curious though; why were kernel outputs being outputted
properly? Shouldn't those have failed to display as well?

>
> Some other OS take these from ISAPNP but OpenBSD hardcodes the
> standard values for a PC-compatible machine and expects the port to
> be there.

Why doesn't OpenBSD attempt to do this as well? Is there some reason to
avoid that, or is it simply because nobody's gotten around to it?

>
> > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> > com0: console
> > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
>

The rebooting issue is now gone too. I had assumed they were related,
and they are.

Thanks,

--
Hugo Osvaldo Barrera

[demime 1.01d removed an attachment of type application/pgp-signature]



Re: mutt: clear your cache (time_t)

2013-08-23 Thread Stuart Henderson
Alexander Polakov  sdf.org> writes:

> 
> I haven't seen this mentioned in current.html, so..
> If you're using mutt's caching options (set header_cache,
> set message_cachedir), clear the cache before upgrading
> to newer snapshot if you're not a fan of 1.4G core files
> lying around.

This will no longer be needed as of the mutt-1.5.21p4v0 packages.



Re: Broken output from serial console

2013-08-23 Thread Stuart Henderson
On 2013-08-23, Hugo Osvaldo Barrera  wrote:
> Hi!
> I've started managing a serial server through a serial console, and have
> come into some unusual issues.
> I followed the instrucitons on faq 7.7, and also configured by BIOS
> accordingly.
>
> When I conect my PC to the server, I see BIOS and POST output properly,
> I then see the OpenBSD bootloader properly, and all the kernel messages come
> out fine (ie: the white-on-blue text), however, AFTER the kernel messages,
> I only see the following sixteen characters and nothing else (though
> later kernel messages like plugging in a USB are shown properly).
>
> In single user mode, this would be:
> "Enter pathname o"
>
> In non-single user mode, this would be
> "Automatic boot i"
>
> It's extremely odd. I'm cleary not having cable issues, wrong rates,
> or anything alike, because I'm seeing kernel output just fine.

This is exactly what you would see if the IRQ assignment is wrong.
There are other possibilities too, but this is easy to check in the
BIOS, and is a somewhat likely problem.

The first port (known as com0 in OpenBSD, com1 in MSDOS) should be at
0x3f8 irq 4, the second should be 0x2f8 irq 3. Sometimes vendors
(I've seen it with Jetway) have been known to screw up and reverse
the irq assignments.

Some other OS take these from ISAPNP but OpenBSD hardcodes the
standard values for a PC-compatible machine and expects the port to
be there.

> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo



Re: mysql.sock location

2013-08-23 Thread Stuart Henderson
On 2013-08-23, Guy Ferguson  wrote:
> liviu,
> At last, I get your name right, if a little under-capitalised.  Your 
> help was the first step in maybe a dozen or so that got the site back 
> up. So thank you kindly for that.  Just some minor linking to outside 
> the chroot and it'll be perfect.

If you have set paths in /etc/my.cnf, then you shouldn't need additional
linking outside the chroot.



Re: EuroBSDCon 2013

2013-08-23 Thread Marc Espie
On Thu, Aug 15, 2013 at 08:07:58PM +0400, Loganaden Velvindron wrote:
> I would be great if someone could record the OpenBSD videos for
> EuroBSDCon 2013 and post
> them on youtube.
> 
> I'm particularly interested in the  Y2038: Going long long on time_t
> to cope with 2,147,483,647+1 talk.
> 
> No offence meant to the VM/VFS hackers out there :-)

AFAIK, it will happen in an official manner, like for last years.
Speakers have been asked if they're okay with it (to which I replied, sure
as long as it's under a bsd-stye licence)



Re: relayd crash

2013-08-23 Thread Bogdan Andu
Hello,

Here are the results of relayd debug:

Version: relayd --current
OS:
OpenBSD 5.3/amd64

 pwd: /usr/src/usr.sbin/relayd

$ sudo ./relayd

$ ps
aux|grep relay
_relayd  10140  0.0  0.1  1180  2984 ??  S 11:37AM   
0:00.01 relayd: relay (relayd)
_relayd  32389  0.0  0.1  1184  2996 ??  S
11:37AM    0:00.01 relayd: relay (relayd)
root 17108  0.0  0.1  1336  3252
??  Ss    11:37AM    0:00.02 relayd: parent (relayd)
_relayd  29445  0.0  0.1 
1136  2744 ??  S 11:37AM    0:00.01 relayd: pfe (relayd)
_relayd  10876 
0.0  0.1   940  2496 ??  S 11:37AM    0:00.01 relayd: hce (relayd)
andu  5868  0.0  0.0   228   124 p0  R+/0  11:37AM    0:00.00 grep relay
PFE:
$ sudo gdb ./relayd
GNU gdb 6.3
Copyright 2004 Free Software Foundation,
Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no
warranty for GDB.  Type "show warranty" for details.
This GDB was configured
as "amd64-unknown-openbsd5.3"...
(gdb) 
(gdb) attach 29445
Attaching to
program: /usr/src/usr.sbin/relayd-current/relayd, process 29445
Loaded symbols
for /usr/src/usr.sbin/relayd-current/relayd
Reading symbols from
/usr/lib/libevent.so.3.1...done.
Loaded symbols for /usr/lib/libevent.so.3.1
Reading symbols from /usr/lib/libssl.so.19.0...done.
Loaded symbols for
/usr/lib/libssl.so.19.0
Reading symbols from
/usr/lib/libcrypto.so.22.0...done.
Loaded symbols for
/usr/lib/libcrypto.so.22.0
Reading symbols from
/usr/lib/libutil.so.11.4...done.
Loaded symbols for /usr/lib/libutil.so.11.4
Reading symbols from /usr/lib/libc.so.66.2...done.
Loaded symbols for
/usr/lib/libc.so.66.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded
symbols for /usr/libexec/ld.so
[Switching to thread 1029445]
0x05462804581a in kevent () at :2
2   : No such file or
directory.
    in 
Current language:  auto; currently asm
(gdb)
continue
Continuing.
Program exited normally.
(gdb) 
The program is not being
run.
(gdb) 

HCE:

$ sudo gdb ./relayd
GNU gdb 6.3
Copyright 2004 Free
Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of
it under certain conditions.
Type "show copying" to see the conditions.
There
is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB
was configured as "amd64-unknown-openbsd5.3"...
(gdb) attach 10876
Attaching
to program: /usr/src/usr.sbin/relayd-current/relayd, process 10876
Loaded
symbols for /usr/src/usr.sbin/relayd-current/relayd
Reading symbols from
/usr/lib/libevent.so.3.1...done.
Loaded symbols for /usr/lib/libevent.so.3.1
Reading symbols from /usr/lib/libssl.so.19.0...done.
Loaded symbols for
/usr/lib/libssl.so.19.0
Reading symbols from
/usr/lib/libcrypto.so.22.0...done.
Loaded symbols for
/usr/lib/libcrypto.so.22.0
Reading symbols from
/usr/lib/libutil.so.11.4...done.
Loaded symbols for /usr/lib/libutil.so.11.4
Reading symbols from /usr/lib/libc.so.66.2...done.
Loaded symbols for
/usr/lib/libc.so.66.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded
symbols for /usr/libexec/ld.so
[Switching to thread 1010876]
0x05462804581a in kevent () at :2
2   : No such file or
directory.
    in 
Current language:  auto; currently asm
(gdb)
(gdb) continue
Continuing.
Program exited normally.
(gdb) 
The program is not
being run.
(gdb) 
The program is not being run.

PARENT:

$ sudo gdb ./relayd
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free
software, covered by the GNU General Public License, and you are
welcome to
change it and/or distribute copies of it under certain conditions.
Type "show
copying" to see the conditions.
There is absolutely no warranty for GDB.  Type
"show warranty" for details.
This GDB was configured as
"amd64-unknown-openbsd5.3"...
(gdb) 
(gdb) attach 17108
Attaching to program:
/usr/src/usr.sbin/relayd-current/relayd, process 17108
Loaded symbols for
/usr/src/usr.sbin/relayd-current/relayd
Reading symbols from
/usr/lib/libevent.so.3.1...done.
Loaded symbols for /usr/lib/libevent.so.3.1
Reading symbols from /usr/lib/libssl.so.19.0...done.
Loaded symbols for
/usr/lib/libssl.so.19.0
Reading symbols from
/usr/lib/libcrypto.so.22.0...done.
Loaded symbols for
/usr/lib/libcrypto.so.22.0
Reading symbols from
/usr/lib/libutil.so.11.4...done.
Loaded symbols for /usr/lib/libutil.so.11.4
Reading symbols from /usr/lib/libc.so.66.2...done.
Loaded symbols for
/usr/lib/libc.so.66.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded
symbols for /usr/libexec/ld.so
[Switching to thread 1017108]
0x05462804581a in kevent () at :2
2   : No such file or
directory.
    in 
Current language:  auto; currently asm
(gdb)
(gdb) continue
Continuing.
Program received signal SIGTERM, Terminated.
0x05462805feea in kill () at :2
2   : No such file or
directory.
    in 
(gdb) 
Conti

Re: mysql.sock location

2013-08-23 Thread Gilbert Sanford
The instructions in /usr/local/share/doc/pkg-readmes/mysql-server-5.1.xx
have always worked for me . . . very handy reference with specific
instructions from ajacoutot@ on "Running mysql-server-5.1.xx on
OpenBSD."

Gilbert



On Fri, Aug 23, 2013 at 4:34 AM, Guy Ferguson  wrote:
> liviu,
> At last, I get your name right, if a little under-capitalised.  Your help
> was the first step in maybe a dozen or so that got the site back up. So
> thank you kindly for that.  Just some minor linking to outside the chroot
> and it'll be perfect.
>
> But thanks for the help.
> guy
>
> On 19/08/2013 02:54, Liviu Daia wrote:
>>
>> On 18 August 2013, Guy Ferguson  wrote:
>>>
>>> Livia,
>>
>>  If you want to address me by name, s/Livia/Liviu/ please.  It might
>> not be much, but it's my name, and I kind of became attached to it over
>> the years. :)
>>
>>> Thanks for your help.
>>>
>>> I modded the /etc/my.cnf to add in the extra "/run" directory.
>>>
>>> A few other tweaks here and there and i can now get a test.php to
>>> connect to the
>>> default host mysql ($conn=mysql_connect...)
>>>
>>> So now i'm confident that mysql is working and connectable...I just
>>> ahve to sort out why drupal is
>>> unhappy, which no doubt is a chroot issue.
>>
>> [...]
>>
>>  Like I said, the easy solution to that is to use TCP connections.
>> As others have pointed out, just set hostname to 127.0.0.1 in your
>> Drupal config, and you should be fine.
>>
>>  If you insist on using UNIX sockets, you probably want to set
>>
>>  socket = /var/www/run/mysql.sock
>>
>> in the /etc/my.cnf, then copy /etc/my.cnf to /var/www/etc/my.cnf, and
>> set
>>
>>  socket = /run/mysql.sock
>>
>> in the client section in /var/www/etc/my.cnf.  There is no advantage in
>> doing things like this though, you'd be just looking for future trouble.
>>
>>  Regards,
>>
>>  Liviu Daia
>>
>>
>>
>> -
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2013.0.3392 / Virus Database: 3211/6584 - Release Date: 08/16/13



Re: relayd crash

2013-08-23 Thread Stuart Henderson
On 2013/08/23 04:03, Bogdan Andu wrote:
> $ sudo gdb ./relayd
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "amd64-unknown-openbsd5.3"...
> (gdb) attach 32389
> Attaching to program: /usr/src/usr.sbin/relayd-current/relayd, process
> 32389
> Loaded symbols for /usr/src/usr.sbin/relayd-current/relayd
> Reading symbols from /usr/lib/libevent.so.3.1...done.
> Loaded symbols for /usr/lib/libevent.so.3.1
> Reading symbols from /usr/lib/libssl.so.19.0...done.
> Loaded symbols for /usr/lib/libssl.so.19.0
> Reading symbols from /usr/lib/libcrypto.so.22.0...done.
> Loaded symbols for /usr/lib/libcrypto.so.22.0
> Reading symbols from /usr/lib/libutil.so.11.4...done.
> Loaded symbols for /usr/lib/libutil.so.11.4
> Reading symbols from /usr/lib/libc.so.66.2...done.
> Loaded symbols for /usr/lib/libc.so.66.2
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> [Switching to thread 1032389]
> 0x05462804581a in kevent () at :2
> 2   : No such file or directory.
> in 
> Current language:  auto; currently asm
> (gdb) continue
> Continuing.
> Program received signal SIGSEGV, Segmentation fault.

A backtrace from this one would be helpful, that will hopefully show the
chain of functions which called event_queue_insert()..

> event_queue_insert (base=0x0, ev=0x54621afd208, queue=8) at /usr/src/
> lib/libevent/event.c:997
> 997 base->event_count++;
> Current language:  auto; currently c
> (gdb)
> Continuing.

> But why this child crashes in /usr/src/lib/libevent/event.c, line 997 ?

It is attempting to dereference a null pointer.

> event_queue_insert (base=0x0, ev=0x54621afd208, queue=8) at 
> /usr/src/lib/libevent/event.c:997
  
> 997 base->event_count++;
  ^^



Re: mysql.sock location

2013-08-23 Thread Guy Ferguson

liviu,
At last, I get your name right, if a little under-capitalised.  Your 
help was the first step in maybe a dozen or so that got the site back 
up. So thank you kindly for that.  Just some minor linking to outside 
the chroot and it'll be perfect.


But thanks for the help.
guy

On 19/08/2013 02:54, Liviu Daia wrote:

On 18 August 2013, Guy Ferguson  wrote:

Livia,

 If you want to address me by name, s/Livia/Liviu/ please.  It might
not be much, but it's my name, and I kind of became attached to it over
the years. :)


Thanks for your help.

I modded the /etc/my.cnf to add in the extra "/run" directory.

A few other tweaks here and there and i can now get a test.php to
connect to the
default host mysql ($conn=mysql_connect...)

So now i'm confident that mysql is working and connectable...I just
ahve to sort out why drupal is
unhappy, which no doubt is a chroot issue.

[...]

 Like I said, the easy solution to that is to use TCP connections.
As others have pointed out, just set hostname to 127.0.0.1 in your
Drupal config, and you should be fine.

 If you insist on using UNIX sockets, you probably want to set

 socket = /var/www/run/mysql.sock

in the /etc/my.cnf, then copy /etc/my.cnf to /var/www/etc/my.cnf, and
set

 socket = /run/mysql.sock

in the client section in /var/www/etc/my.cnf.  There is no advantage in
doing things like this though, you'd be just looking for future trouble.

 Regards,

 Liviu Daia



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3211/6584 - Release Date: 08/16/13