Re: pf set prio
* Михаил Швецов [2013-06-13 16:54]: > Does (pf set prio) work on Openbsd 5.3 x64 or i386? of course. > Please can you write simple config for set prio in pf.conf? match set prio 5
Re: tftpd loop
what does "host -- -c" say? On 29/06/2013, at 3:54 AM, Peter Fraser wrote: > tftpd -l -c xxx > > resulting from a mistyping causes tftpd to into a loop
Re: puzzling nginx behavior on OpenBSD
I have my config file as such,
location ~ \.php$ {
root /htdocs;
fastcgi_pass unix:/tmp/php.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /htdocs$fastcgi_script_name;
include fastcgi_params;
}
On 07/01/2013 10:07 PM, Salil Wadnerkar wrote:
> Hi,
>
> I specified the root explicitly (I think, by default it looks into
> /var/www/htdocs), but that did not help.
> I started the nginx in unsafe mode (non-chrooted mode) by specifying the
> "-u" flag. I also tried unix socket communication between nginx and fastcgi
> with the socket file in /var/www/ directory (though, the location is not
> important in a non-chrooted mode), but that did not help either.
> Anyway, thank you all of you for trying to help. I have deeper
> understanding of nginx and OpenBSD now.
>
> best regards
> Salil
>
>
> On Mon, Jul 1, 2013 at 11:08 PM, wrote:
>
>> Maybe you'll have more luck trying out the Nginx port (/etc/rc.d/enginx)
>> rather than the default chrooted one?
>>
>>
>> http://openbsd.7691.n7.nabble.com/Ruby-on-Rails-and-the-chrooted-nginx-8-td229745.html
>>
>> O.D.
>>
>> On 1. juli 2013 at 5:57 AM, "Salil Wadnerkar" wrote:
>>> Hi,
>>>
>>> I am testing one C++ fastcgi program on nginx. I modified my nginx
>>> config
>>> by adding this
>>> block:
>>>
>>> -- /usr/local/share/nginx/nginx.conf ---
>>>
>>>server {
>>> listen 80;
>>> server_name localhost;
>>>
>>># pass the C++ scripts to FastCGI server listening on
>>> 127.0.0.1:8000
>>> #
>>> location ~ \.cpp$ {
>>> fastcgi_pass 127.0.0.1:8000;
>>> fastcgi_param SCRIPT_FILENAME
>>> $document_root$fastcgi_script_name;
>>> includefastcgi_params;
>>> }
>>>
>>> I run my fastcgi application using spawn-fcgi:
>>>
>>> spawn-fcgi -p 8000 -n cppreadings
>>>
>>> And I access the cpp url like this:
>>> curl http://localhost/index.cpp
>>>
>>> But, I get the error that the URL is not available and my nginx
>>> error log
>>> shows:
>>>
>>> -- /var/www/logs/error.log ---
>>>
>>> 2013/07/01 21:21:07 [error] 28733#0: *1 open() "/htdocs/index.cpp"
>>> failed
>>> (2: No such file or directory), client: 127.0.0.1, server:
>>> localhost,
>>> request: "GET /index.cpp HTTP/1.1", host: "localhost"
>>>
>>> I am puzzled as to why it is taking the URL as /htdocs/index.cpp
>>> and
>>> probably, that is the reason why it is failing. I can attach my
>>> nginx.conf,
>>> if anybody wants to view the complete config. But, basically the
>>> above is
>>> the only change I made to the default nginx config.
>>>
>>> I am using the exact same config on Mac OS X and Arch Linux and it
>>> is
>>> working there.
>>> So, that'w why I am posting it in OpenBSD forum rather than nginx
>>> forum.
>>>
>>> Thanks
>>> Salil
--
Salim A. Shaw
System Administrator
OpenBSD & CentOS / Free Software Advocate
Need stability and security -- Try OpenBSD.
BSD,ISC license all the way: Sell services, don't lease secrets
Re: puzzling nginx behavior on OpenBSD
Hi,
I specified the root explicitly (I think, by default it looks into
/var/www/htdocs), but that did not help.
I started the nginx in unsafe mode (non-chrooted mode) by specifying the
"-u" flag. I also tried unix socket communication between nginx and fastcgi
with the socket file in /var/www/ directory (though, the location is not
important in a non-chrooted mode), but that did not help either.
Anyway, thank you all of you for trying to help. I have deeper
understanding of nginx and OpenBSD now.
best regards
Salil
On Mon, Jul 1, 2013 at 11:08 PM, wrote:
> Maybe you'll have more luck trying out the Nginx port (/etc/rc.d/enginx)
> rather than the default chrooted one?
>
>
> http://openbsd.7691.n7.nabble.com/Ruby-on-Rails-and-the-chrooted-nginx-8-td229745.html
>
> O.D.
>
> On 1. juli 2013 at 5:57 AM, "Salil Wadnerkar" wrote:
> >
> >Hi,
> >
> >I am testing one C++ fastcgi program on nginx. I modified my nginx
> >config
> >by adding this
> >block:
> >
> >-- /usr/local/share/nginx/nginx.conf ---
> >
> > server {
> >listen 80;
> >server_name localhost;
> >
> > # pass the C++ scripts to FastCGI server listening on
> >127.0.0.1:8000
> >#
> >location ~ \.cpp$ {
> >fastcgi_pass 127.0.0.1:8000;
> >fastcgi_param SCRIPT_FILENAME
> > $document_root$fastcgi_script_name;
> >includefastcgi_params;
> >}
> >
> >I run my fastcgi application using spawn-fcgi:
> >
> >spawn-fcgi -p 8000 -n cppreadings
> >
> >And I access the cpp url like this:
> >curl http://localhost/index.cpp
> >
> >But, I get the error that the URL is not available and my nginx
> >error log
> >shows:
> >
> >-- /var/www/logs/error.log ---
> >
> >2013/07/01 21:21:07 [error] 28733#0: *1 open() "/htdocs/index.cpp"
> >failed
> >(2: No such file or directory), client: 127.0.0.1, server:
> >localhost,
> >request: "GET /index.cpp HTTP/1.1", host: "localhost"
> >
> >I am puzzled as to why it is taking the URL as /htdocs/index.cpp
> >and
> >probably, that is the reason why it is failing. I can attach my
> >nginx.conf,
> >if anybody wants to view the complete config. But, basically the
> >above is
> >the only change I made to the default nginx config.
> >
> >I am using the exact same config on Mac OS X and Arch Linux and it
> >is
> >working there.
> >So, that'w why I am posting it in OpenBSD forum rather than nginx
> >forum.
> >
> >Thanks
> >Salil
Softraid performance: CRYPTO on top of RAID 1?
Hi folks, Anyone having any experience with putting an softraid CRYPTO partition on top of a softraid RAID 1? In terms of performance? I'd like to build a file server that favors redundancy, availability and privacy over performance. The latter within limits though, hence my initial question. Private use only. Me, my family and ... friends. I'm planning to use 3 x 1TB drives in RAID 1. No FDE since "availability" involves the possibility of unattended booting; like after a power outage while being abroad/out of town, in which case I'd have to ssh in to the box and bioctl(8) the encrypted volume. Otherwise the PC is an old Pentium 4 3.40GHz with 3GB RAM which as of today runs fine as a file server with 2 x 500GB disks in softraid RAID 1. Sorry if my question does not belong on @misc. I've done quite some homework but could not find information pertinent to my case and would like to hear any arguments for or against before I spend many hours on copying hundres of gigabytes to potentially no avail. Regards, Erling
Re: OpenBSD Doesn't Support 64-Bit Intel
carlos albino garcia grijalba wrote: IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! dont complain if u really dont read all of the info (i understand now why my questions are not answered LOL) No. If you're going to respond, at least get it right... IA64 *isn't* x86. Date: Mon, 1 Jul 2013 00:06:05 -0400 Subject: OpenBSD Doesn't Support 64-Bit Intel From: jash.seffer...@gmail.com To: misc@openbsd.org; s...@openbsd.org Hi guys. I’m a civil engineer by day and use OpenBSD at night, but I’m trying to do high-end CAD on my home PC and OpenBSD doesn’t support 64-bit Intel chips. Don't believe me? It says very clearly at the OpenBSD/amd64 page: “All versions of the AMD Athlon 64 processors and their clones are supported.” But does not mention or list any Intel chips. Not one. Wtf? I can do CAD on my i7-980X under Windows 7 SP 1, but I’d rather use something secure and responsibly coded like OpenBSD. Except that I can't. Why for the life of this platform are we not on the only future direction for the platform? And I mean that literally. Neither AMD nor Intel sells 32-bit chips anymore. If OpenBSD remains stuck at 32 bits, people will stop using and developing for it. Who makes the decision to keep OpenBSD off of 64-bit Intel? And why the hell are they doing so? -jash
Re: IETF-87 in Berlin
On 2013-06-30, Loganaden Velvindron wrote: > Hey guys, > > I was wondering if any of you will be at IETF-87 in Berlin :-) ? > > Not me. But I can lend an axe if anyone's thinking of going :-)
Re: panic: pool_do_get(mcl2k): free list modified
Following up on my previous report, I've had this panic again, this time on the June 27th snap. Customary information and dmesg below. thanks, .jh ddb> show panic pool_do_get(mcl2k): free list modified: page 0xfe80cbcc8000; item addr 0xfe80cbcc8000; offset 0x0=0x100e ddb> trace Debugger() at Debugger+0x5 panic() at panic+0xe4 pool_do_get() at pool_do_get+0x3e9 pool_get() at pool_get+0x4a m_clget() at m_clget+0x95 em_get_buf() at em_get_buf+0x8b em_rxfill() at em_rxfill+0x68 em_intr() at em_intr+0xc8 end of kernel end trace frame: 0xcfb2fc330d0, count: -8 ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND 32645 1 2458539 3 0x4100080 thrsleep clamd 1130448448507 30x80 poll smtp 9685 15239 9685503 30x80 netio postgres 28729448448507 2 0cleanup 5410 15239 5410503 30x80 netio postgres 11611 15239 11611503 30x80 netio postgres 1132448448507 30x80 kqreadtrivial-rewrite 1529448448507 30x80 kqreadproxymap 25236448448507 30x80 poll smtpd 19017 21933 21933 0 30x80 kqreadssl-params 4404 21933 21933507 30x80 kqreadimap 4315 21933 21933518 30x80 kqreadimap-login 24644 21933 21933 1000 30x80 kqreadimap 17218 21933 21933518 30x80 kqreadimap-login 20633448448507 30x80 kqreadanvil 29389 15239 29389503 30x80 netio postgres 27474 21933 21933 0 30x80 kqreadauth 31665 21933 21933 1000 30x80 kqreadimap 24280 21933 21933518 30x80 kqreadimap-login 14393 21933 21933507 30x80 kqreadimap 24285 21933 21933518 30x80 kqreadimap-login 32245448448507 30x80 kqreadpickup 26051 21933 21933518 30x80 kqreadimap-login 12221 21933 21933518 30x80 kqreadimap-login 5918 21933 21933518 30x80 kqreadimap-login 26812 21933 21933518 30x80 kqreadimap-login 23207 5599 5599 67 30x80 netconphp-fpm-5.3 29448 21933 21933 1000 30x80 kqreadimap 28123 21933 21933518 30x80 kqreadimap-login 24213 21933 21933 1000 30x80 kqreadimap 28952 21933 21933518 30x80 kqreadimap-login 24585 5599 5599 67 30x80 netconphp-fpm-5.3 26631 21933 21933518 30x80 kqreadimap-login 10243 21933 21933518 30x80 kqreadimap-login 4377 21933 21933518 30x80 kqreadimap-login 20261 21933 21933518 30x80 kqreadimap-login 21739 21933 21933518 30x80 kqreadimap-login 5161 21933 21933507 30x80 kqreadimap 11947 21933 21933518 30x80 kqreadimap-login 3332 13948 13948530 30x80 lockf perl 7533 21933 21933507 30x80 kqreadimap 18485 21933 21933518 30x80 kqreadimap-login 30004 25962 25962506 30x80 selectperl *27515 13948 13948530 7 0perl 5059 13948 13948530 30x80 selectperl 20636 21933 21933507 30x80 kqreadimap 12706 21933 21933518 30x80 kqreadimap-login 7776 19304 7776 1000 30x80 selectssh 19304 7175 19304 1000 30x88 pause ksh 29765 18087 29765 1000 30x80 selectssh 18087 7175 18087 1000 30x88 pause ksh 17325 15967 15967 67 30x80 netconhttpd 5757 6203 5757 0 30x80 ttyin ksh 32182448448507 30x80 kqreadtlsmgr 10974 20518 20518 1000 3 0x4100080 poll irssi 1125 20518 20518 1000 30x80 poll irssi 5524 7175 5524 1000 30x80 ttyin ksh 23596 7175 23596 1000 30x80 ttyin ksh 6203 7175 6203 1000 30x88 pause ksh 20518 7175 20518 1000 30x88 pause ksh 7175 1 7175 1000 30x80 kqreadtmux 26395 1 26395 0 30x80 ttyin getty 2715 1 2715 0 30x80 ttyin getty 5890 1 5890 0 30x80 ttyin getty 26968 1 26968 0 30x80 ttyin getty 25086 1 25086
Re: Can't compile binaries :/
On 7/1/2013 22:11 PM, jV wrote: I'm using patch branch, not current. On 7/1/2013 22:11 PM, Daniel Bolgheroni wrote: On Mon, Jul 01, 2013 at 09:54:48PM +0300, jV wrote: Any ideas why it keeps failing here ? http://openbsd.org/faq/current.html proof: [root@OPENBS1: S]# cat /usr/src/CVS/Tag TOPENBSD_5_3 [root@OPENBSD1: S]#
Re: Can't compile binaries :/
I'm using patch branch, not current. On 7/1/2013 22:11 PM, Daniel Bolgheroni wrote: On Mon, Jul 01, 2013 at 09:54:48PM +0300, jV wrote: Any ideas why it keeps failing here ? http://openbsd.org/faq/current.html
Re: Can't compile binaries :/
On Mon, Jul 01, 2013 at 09:54:48PM +0300, jV wrote: > > Any ideas why it keeps failing here ? http://openbsd.org/faq/current.html
Can't compile binaries :/
Hey, I'm trying to recompile binaries, but this task keeps failing. I have tried to remove everything from /usr/src and extracted everything from src/sys.tgz and updated from cvs, but this didn't help. Any help would be appreciated. ===> sys/arch/amd64/stand/pxeboot sh /usr/src/sys/arch/amd64/stand/pxeboot/../../../../kern/genassym.sh cc -Os -Wall -Werror -fno-stack-protector -m32 -D_STANDALONE -nostdinc -fno-builtin -fpack-struct -D__INTERNAL_LIBSA_CREAD -fno-pie -I/usr/src/sys/arch/amd64/stand/pxeboot/../../../.. -I/usr/src/sys/arch/amd64/stand/pxeboot/../libsa -I. -I/usr/src/sys/arch/amd64/stand/pxeboot -DSOFTRAID -DBOOTMAGIC=0xc001d00d -DLINKADDR=0x40120 -DSLOW -DSMALL -DNOBYFOUR -DNO_GZIP -DDYNAMIC_CRC_TABLE -DHEAP_LIMIT=0x9 -I/usr/src/sys/arch/amd64/stand/pxeboot/../../../../stand/boot < /usr/src/sys/arch/amd64/stand/pxeboot/../etc/genassym.cf > assym.h.tmp && mv -f assym.h.tmp assym.h mkdep -a -D_STANDALONE -D__INTERNAL_LIBSA_CREAD -I/usr/src/sys/arch/amd64/stand/pxeboot/../../../.. -I/usr/src/sys/arch/amd64/stand/pxeboot/../libsa -I. -I/usr/src/sys/arch/amd64/stand/pxeboot -DSOFTRAID -DBOOTMAGIC=0xc001d00d -DLINKADDR=0x40120 -DSLOW -DSMALL -DNOBYFOUR -DNO_GZIP -DDYNAMIC_CRC_TABLE -DHEAP_LIMIT=0x9 -I/usr/src/sys/arch/amd64/stand/pxeboot/../../../../stand/boot /usr/src/sys/arch/amd64/stand/pxeboot/srt0.S /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/gidt.S /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/alloca.S /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/pxe_call.S mkdep -a -D_STANDALONE -D__INTERNAL_LIBSA_CREAD -I/usr/src/sys/arch/amd64/stand/pxeboot/../../../.. -I/usr/src/sys/arch/amd64/stand/pxeboot/../libsa -I. -I/usr/src/sys/arch/amd64/stand/pxeboot -DSOFTRAID -DBOOTMAGIC=0xc001d00d -DLINKADDR=0x40120 -DSLOW -DSMALL -DNOBYFOUR -DNO_GZIP -DDYNAMIC_CRC_TABLE -DHEAP_LIMIT=0x9 -I/usr/src/sys/arch/amd64/stand/pxeboot/../../../../stand/boot /usr/src/sys/arch/amd64/stand/pxeboot/conf.c /usr/src/sys/arch/amd64/stand/pxeboot/devopen.c /usr/src/sys/arch/amd64/stand/pxeboot/net.c /usr/src/sys/arch/amd64/stand/pxeboot/open.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/machdep.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/exec_i386.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/cmd_i386.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/biosdev.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/bioscons.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/gateA20.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/memprobe.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/diskprobe.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/time.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/pxe.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/pxe_net.c /usr/src/sys/arch/amd64/stand/pxeboot/../libsa/softraid.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../stand/boot/boot.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../stand/boot/cmd.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../stand/boot/vars.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../stand/boot/bootarg.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/alloc.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/exit.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/getfile.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/gets.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/globals.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/strcmp.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/strlen.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/strncmp.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/memcmp.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/memcpy.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/memset.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/printf.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/snprintf.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/strerror.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/strncpy.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/strtol.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/strtoll.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/ctime.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libkern/strlcpy.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libkern/strlcat.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/aes_xts.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/explicit_bzero.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/hmac_sha1.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/pbkdf2.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/rijndael.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/sha1.c /usr/src/sys/arch/amd64/stand/pxeboot/../../../../lib/libsa/clo
nwflag hidenwid : SIOCS80211FLAGS: Invalid argument
Hi Everybody, On my OpenBSD 5.3 GENERIC.MP#62 amd64, I am trying to set the nwflag to hidenwid of my athn0 but I have the following error: $ ifconfig athn0 inet 10.0.1.1 netmask 255.255.255.0 media autoselect mediaopt hostap nwid test chan 6 nwflag hidenwid up ifconfig: SIOCS80211CHANNEL: Invalid argument Someone had reported this issue in the past : http://archives.neohapsis.com/archives/openbsd/2006-10/1793.html. Like mentionned, I have tried to move the nwflag in the command line (or in /etc/hostname.athn0, even put nwflag hidenwid in the second line), but no success. Does anybody have a working configuration ? Thanks for your help, = Here are my hardware info : $ dmesg | grep athn athn0 at pci2 dev 0 function 0 "Atheros AR5418" rev 0x01: apic 4 int 17 athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 8, address 00:21:63:a4:3a:28 $ pkg_info | grep firmware athn-firmware-1.1p0 firmware binary images for athn(4) driver $ ifconfig athn0 media athn0: flags=8803 mtu 1500 lladdr 00:21:63:a4:3a:28 priority: 4 groups: wlan media: IEEE802.11 autoselect status: no network ieee80211: nwid test chan 6 supported media: media autoselect media autoselect mediaopt hostap media autoselect mediaopt monitor media autoselect mode 11a media autoselect mode 11a mediaopt hostap media autoselect mode 11a mediaopt monitor media OFDM6 mode 11a media OFDM6 mode 11a mediaopt hostap media OFDM6 mode 11a mediaopt monitor media OFDM9 mode 11a media OFDM9 mode 11a mediaopt hostap media OFDM9 mode 11a mediaopt monitor media OFDM12 mode 11a media OFDM12 mode 11a mediaopt hostap media OFDM12 mode 11a mediaopt monitor media OFDM18 mode 11a media OFDM18 mode 11a mediaopt hostap media OFDM18 mode 11a mediaopt monitor media OFDM24 mode 11a media OFDM24 mode 11a mediaopt hostap media OFDM24 mode 11a mediaopt monitor media OFDM36 mode 11a media OFDM36 mode 11a mediaopt hostap media OFDM36 mode 11a mediaopt monitor media OFDM48 mode 11a media OFDM48 mode 11a mediaopt hostap media OFDM48 mode 11a mediaopt monitor media OFDM54 mode 11a media OFDM54 mode 11a mediaopt hostap media OFDM54 mode 11a mediaopt monitor media autoselect mode 11b media autoselect mode 11b mediaopt hostap media autoselect mode 11b mediaopt monitor media DS1 mode 11b media DS1 mode 11b mediaopt hostap media DS1 mode 11b mediaopt monitor media DS2 mode 11b media DS2 mode 11b mediaopt hostap media DS2 mode 11b mediaopt monitor media DS5 mode 11b media DS5 mode 11b mediaopt hostap media DS5 mode 11b mediaopt monitor media DS11 mode 11b media DS11 mode 11b mediaopt hostap media DS11 mode 11b mediaopt monitor media autoselect mode 11g media autoselect mode 11g mediaopt hostap media autoselect mode 11g mediaopt monitor media DS1 mode 11g media DS1 mode 11g mediaopt hostap media DS1 mode 11g mediaopt monitor media DS2 mode 11g media DS2 mode 11g mediaopt hostap media DS2 mode 11g mediaopt monitor media DS5 mode 11g media DS5 mode 11g mediaopt hostap media DS5 mode 11g mediaopt monitor media DS11 mode 11g media DS11 mode 11g mediaopt hostap media DS11 mode 11g mediaopt monitor media OFDM6 mode 11g media OFDM6 mode 11g mediaopt hostap media OFDM6 mode 11g mediaopt monitor media OFDM9 mode 11g media OFDM9 mode 11g mediaopt hostap media OFDM9 mode 11g mediaopt monitor media OFDM12 mode 11g media OFDM12 mode 11g mediaopt hostap media OFDM12 mode 11g mediaopt monitor media OFDM18 mode 11g media OFDM18 mode 11g mediaopt hostap media OFDM18 mode 11g mediaopt monitor media OFDM24 mode 11g media OFDM24 mode 11g mediaopt hostap media OFDM24 mode 11g mediaopt monitor media OFDM36 mode 11g media OFDM36 mode 11g mediaopt hostap media OFDM36 mode 11g mediaopt monitor media OFDM48 mode 1
Re: OpenBSD Doesn't Support 64-Bit Intel
On Mon, Jul 1, 2013 at 7:48 AM, carlos albino garcia grijalba wrote: > IA64 its the name of the arch for the processor created originali by AMD and > INTEL copied so support for AMD64 mean INTEL64 too! No, IA-64 refers to the Itanium architecture, which is very different from AMD64/Intel 64.
Re: OpenBSD Doesn't Support 64-Bit Intel
Hate to burst your bubble here but 64bit x86 is also known as AMD64 since AMD was the first to bring x86-64 to market since Intel at the time had the attitude of "why would any one want 64bit" On 2013-06-30 21:06, Jash Sefferson wrote: Hi guys. I’m a civil engineer by day and use OpenBSD at night, but I’m trying to do high-end CAD on my home PC and OpenBSD doesn’t support 64-bit Intel chips. Don't believe me? It says very clearly at the OpenBSD/amd64 page: “All versions of the AMD Athlon 64 processors and their clones are supported.” But does not mention or list any Intel chips. Not one. Wtf? I can do CAD on my i7-980X under Windows 7 SP 1, but I’d rather use something secure and responsibly coded like OpenBSD. Except that I can't. Why for the life of this platform are we not on the only future direction for the platform? And I mean that literally. Neither AMD nor Intel sells 32-bit chips anymore. If OpenBSD remains stuck at 32 bits, people will stop using and developing for it. Who makes the decision to keep OpenBSD off of 64-bit Intel? And why the hell are they doing so? -jash -- Jason Barbier C:(206)650-6542|E:jab...@serversave.us
Re: OpenBSD Doesn't Support 64-Bit Intel
This just seems like a bad troll. What high-end CAD product (or any commercial CAD product) runs natively on OpenBSD?
Re: OpenBSD Doesn't Support 64-Bit Intel
IA64 its the name of the arch for the processor created originali by AMD and INTEL copied so support for AMD64 mean INTEL64 too! dont complain if u really dont read all of the info (i understand now why my questions are not answered LOL) > Date: Mon, 1 Jul 2013 00:06:05 -0400 > Subject: OpenBSD Doesn't Support 64-Bit Intel > From: jash.seffer...@gmail.com > To: misc@openbsd.org; s...@openbsd.org > > Hi guys. > > Im a civil engineer by day and use OpenBSD at night, but Im trying to do > high-end CAD on my home PC and OpenBSD doesnt support 64-bit Intel chips. > > Don't believe me? It says very clearly at the OpenBSD/amd64 page: All > versions of the AMD Athlon 64 processors and their clones are supported. > But does not mention or list any Intel chips. Not one. > > Wtf? I can do CAD on my i7-980X under Windows 7 SP 1, but Id rather > use something secure and responsibly coded like OpenBSD. Except that I > can't. > > Why for the life of this platform are we not on the only future direction > for the platform? And I mean that literally. Neither AMD nor Intel sells > 32-bit chips anymore. If OpenBSD remains stuck at 32 bits, people will stop > using and developing for it. > > Who makes the decision to keep OpenBSD off of 64-bit Intel? And why the > hell are they doing so? > > -jash
Re: puzzling nginx behavior on OpenBSD
Maybe you'll have more luck trying out the Nginx port (/etc/rc.d/enginx) rather
than the default chrooted one?
http://openbsd.7691.n7.nabble.com/Ruby-on-Rails-and-the-chrooted-nginx-8-td229745.html
O.D.
On 1. juli 2013 at 5:57 AM, "Salil Wadnerkar" wrote:
>
>Hi,
>
>I am testing one C++ fastcgi program on nginx. I modified my nginx
>config
>by adding this
>block:
>
>-- /usr/local/share/nginx/nginx.conf ---
>
> server {
>listen 80;
>server_name localhost;
>
> # pass the C++ scripts to FastCGI server listening on
>127.0.0.1:8000
>#
>location ~ \.cpp$ {
>fastcgi_pass 127.0.0.1:8000;
>fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
>includefastcgi_params;
>}
>
>I run my fastcgi application using spawn-fcgi:
>
>spawn-fcgi -p 8000 -n cppreadings
>
>And I access the cpp url like this:
>curl http://localhost/index.cpp
>
>But, I get the error that the URL is not available and my nginx
>error log
>shows:
>
>-- /var/www/logs/error.log ---
>
>2013/07/01 21:21:07 [error] 28733#0: *1 open() "/htdocs/index.cpp"
>failed
>(2: No such file or directory), client: 127.0.0.1, server:
>localhost,
>request: "GET /index.cpp HTTP/1.1", host: "localhost"
>
>I am puzzled as to why it is taking the URL as /htdocs/index.cpp
>and
>probably, that is the reason why it is failing. I can attach my
>nginx.conf,
>if anybody wants to view the complete config. But, basically the
>above is
>the only change I made to the default nginx config.
>
>I am using the exact same config on Mac OS X and Arch Linux and it
>is
>working there.
>So, that'w why I am posting it in OpenBSD forum rather than nginx
>forum.
>
>Thanks
>Salil
Re: OpenBSD Doesn't Support 64-Bit Intel
On 07/01/2013 09:27 AM, noah pugsley wrote: ... At first I thought this was a wonderful troll. Guy's got a point though. Look at the i386 page. http://www.openbsd.org/i386.html: Supported hardware: The list of supported hardware is relevant to OpenBSD-current. It will differ slightly from the support provided in the latest release version. Processors All CPU chips compatible with the Intel 80386 (i386) architecture, except for the 80386 itself, are supported: 80486 (DX/DX2/DX4) ...[snip painful, incomplete list]... Transmeta TM3200, TM5400, TM5600, TM5800 Regular floating-point coprocessors (80487SX) are required when not built into the processor. really, I think that's more wrong. Trying to itemize the list when various manufacturers are constantly cranking out new and reusing old names is misleading in the other direction. I think it could be reduced to just: Everything that is a clone of the 486 or up should work fine. maybe adding a blurb about how a standard hardware FPU is required, as someone out there might still have some 486SX systems laying around. This is easier than amd64... just about everything works, and if it doesn't, it is not likely a processor issue. amd64...well, some of the Intel chips, you just need (or it is easier) to test to find out if you got the right bit of magic. Nick.
Re: MariaDB and OpenBSD
If I understand correctly, mariadb packages on OpenBSD machine (5.3, amd64) should work fine, only the client has these posix issues on platforms other than i386 or amd64. and as far as I can see the integration of mariadb in OpenBSD on archs other than i386 or amd64 depends on the implementation of that assembler code. Having these in mind what is the roadmap of integrating mariadb in OpenBSD? Bogdan From: Stuart Henderson To: Bogdan Andu ; Bogdan Andu ; "misc@openbsd.org" Sent: Monday, July 1, 2013 11:04 AM Subject: Re: MariaDB and OpenBSD The relevant code is in the client library and if I remember correctly is just used for asynchronous access functions. It won't affect your use of the server on Linux x86/x86_64. The relevant code is written in assembler for amd64/i386 and for other arches it falls back to using ucontext.h functions specified by an old version of posix which were never implemented on OpenBSD. They were marked 'obsokescent' in newer posix due to a dependency on an obsolescent C language feature (see 'rationale' in http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html) so can't be used in strictly posix-conforming software. They aren't widely used (I've only seen it in mariadb and powerdns-recursor) and unlikely to be added to OpenBSD. (For some uses, boost's context library might be an alternative, though I'm unsure about arch support). Bogdan Andu wrote: > > >maybe the fact that mariadb packages built correctly made me blind >enough to forget about any other package that might depend on mysql >and not mariadb libraries, and curiously enough p5-DBD-mysql was one of >them, which I modified it to suport mariadb > > >i was excited to use mariadb on my OpenBSD machines. > >i'll clean'em up and i'll switch back to mysql-5.1 packages. > >i have a some remaining bits, though left in the dark namely, >concerning that cryptic message from cvs : > >"Revert back to using MySQL 5.1 for the time being. MariaDB 5.5 >introduces >a new libmysqlclient non-blocking API which utilizes co-routines. The >X86 >specific GCC ASM co-routine support hid the fact that there was an >issue. >The only fallback code so far is POSIX user contexts which OpenBSD does >not >support." > >Please if someone can shed more light upon this comment, because it >seems that it has impact on linux also >and based on this comment, which seems to me very important, I want to >know if it is safe to run mariadb server >on linux also, as I do currently on an Ubuntu 13.04 linux x86_64 . > >Thank you all , for your comments, > >Bogdan > > > > From: Stuart Henderson >To: Bogdan Andu ; Bogdan Andu ; >"misc@openbsd.org" >Sent: Monday, July 1, 2013 10:01 AM >Subject: Re: MariaDB and OpenBSD > > >You are trying to use a -current ports tree on 5.3 which is not >supported and you can have various problems as a result of this. > >Also mariadb is not currently enabled in the ports tree. It is setup to >use mysql not mariadb so you're going to have to modify the port for >anything you're installing which uses mysql. > > >Bogdan Andu wrote: > >>on that machine I have imported mariadb in >>/usr/ports/databases/mariadb, via cvs, which compiled ok. >> >>The problem was with p5-DBD-mysql needed by mariadb-server-5.5.31p0, >>which refuses to install without it, and for that reason I had to >>generate a p5-DBD-mysql for mariadb, using the Makefile rev. 1.36 for >>that package. >> >>I took the following steps: >>1. checkout mariadb from cvs repository into >> /usr/ports/databases/mariadb >>2. compiled and generated the packages mariadb-server-5.5.31p0 and >>mariadb-client-5.5.31p0; >>3. removed mysql* packages (client and server) because of conflicts >>4. when tried to install newlly generated mariadb-server-5.5.31p0 it >>required >> p5-DBD-mysql, but p5-DBD-mysql depends on mysql-* stuff; >>5. I removed p5-DBD-mysql; >>6. I update the Makefile with rev. 1.36 in >>/usr/ports/databases/p5-DBD-mysql/Makefile to make it mariadb >>compatible >>7. I did sudo make install for p5-DBD-mysql >>8. sudo pkg_add mariadb-server-5.5.31p0 >>9. sudo pkg_add mariadb-client-5.5.31p0 >> >> >>both client and server are working, but programmaticaly I encountered >>that error which seems to be solved, as Stefan Sperling suggested, via >>LD_PRELOAD env, var. >> >>what I am doing wrong? >> >> >> >> >> From: Stuart Henderson >>To: misc@openbsd.org >>Sent: Saturday, June 29, 2013 1:19 AM >>Subject: Re: MariaDB and OpenBSD >> >> >>On 2013-06-28, Bogdan Andu wrote: >>> Hello, >>> >>> I have installed mariadb-server-5.5.31p0 and mariadb-client-5.5.31p0 >>> on an OpenBSD 5.3 amd64 machine. >> >>http://www.openbsd.org/faq/faq15.html#NoFun
Re: OpenBSD Doesn't Support 64-Bit Intel
On Sun, Jun 30, 2013 at 9:16 PM, STeve Andre' wrote: > On 07/01/13 00:06, Jash Sefferson wrote: > >> Hi guys. >> >> Im a civil engineer by day and use OpenBSD at night, but Im trying to do >> high-end CAD on my home PC and OpenBSD doesnt support 64-bit Intel chips. >> >> Don't believe me? It says very clearly at the OpenBSD/amd64 page: All >> versions of the AMD Athlon 64 processors and their clones are supported. >> But does not mention or list any Intel chips. Not one. >> >> Wtf? I can do CAD on my i7-980X under Windows 7 SP 1, but Id rather >> use something secure and responsibly coded like OpenBSD. Except that I >> can't. >> >> Why for the life of this platform are we not on the only future direction >> for the platform? And I mean that literally. Neither AMD nor Intel sells >> 32-bit chips anymore. If OpenBSD remains stuck at 32 bits, people will >> stop >> using and developing for it. >> >> Who makes the decision to keep OpenBSD off of 64-bit Intel? And why the >> hell are they doing so? >> >> -jash >> >> >> Um I'm writing this on an amd64 Thinkpad W500 which has a > 2.8GHz core two duo. So I don't understand what you mean. > > --STeve Andre' > > At first I thought this was a wonderful troll. Guy's got a point though. Look at the i386 page. http://www.openbsd.org/i386.html: Supported hardware: The list of supported hardware is relevant to OpenBSD-current. It will differ slightly from the support provided in the latest release version. Processors All CPU chips compatible with the Intel 80386 (i386) architecture, except for the 80386 itself, are supported: 80486 (DX/DX2/DX4) Intel Pentium/Pentium-MMX Intel Pentium Pro/II/III/Celeron/Xeon Intel Pentium 4/D Intel Pentium M Intel Core Intel Core 2 (Also see OpenBSD/amd64 for 64-bit support) Intel Atom (Also see OpenBSD/amd64 for 64-bit support) AMD 5x86 AMD K5/K6/K6-2/K6-3 AMD Athlon/Duron/Sempron AMD Athlon 64/Opteron/Turion/Phenom (Also see OpenBSD/amd64 for 64-bit support) Cyrix MediaGX/M1/M2 Cyrix 6x86 VIA C3/C7 Rise mP6 IDT WinChip and C3 NexGen 586 NS Geode GX1 and M1 AMD Geode GX/LX/NX Transmeta TM3200, TM5400, TM5600, TM5800 Regular floating-point coprocessors (80487SX) are required when not built into the processor. Everything that is a clone of the 486 or up should work fine.
Re: syslog.conf tabs vs spaces
On Mon, Jul 01, 2013 at 01:21:28PM +0200, Jan Stary wrote: > Laughably, I got bitten again: > > The selector field is separated from the action field > by one or more tab characters. > > A tab is a tab, not a few spaces. Again, I copied > a syslog.conf line from another xterm after an upgrade > and spent half an hour wondering why my logfile stays empty. > > This is entirely user error, but anyway: > is it on purpose that we require the separators > to be tabs, not spaces? I understand this is > what the original syslog had. This may cause compatibility issues and head-scratching if you switch to a replacement. There are some in the ports tree, I don't know if they support spaces. More over, looks like it's intentional, more or less. Yes, it does mean that those fields may contain spaces. And the rest of the config file parser looks like it's very thorough (zaps trailing spaces and all that). > Would there be any opposition to also allowing spaces? > The '\t' seems to be hardcoded into usr.sbin/syslogd.c > but it seems easy enough to extend it to allow ' ' as well. > > If we stay with tabs only, should the manpage emphasize "not spaces"? "tab character" means exactly what it does. Sorry that it got you, but NO WAY.
syslog.conf tabs vs spaces
Laughably, I got bitten again: The selector field is separated from the action field by one or more tab characters. A tab is a tab, not a few spaces. Again, I copied a syslog.conf line from another xterm after an upgrade and spent half an hour wondering why my logfile stays empty. This is entirely user error, but anyway: is it on purpose that we require the separators to be tabs, not spaces? I understand this is what the original syslog had. Would there be any opposition to also allowing spaces? The '\t' seems to be hardcoded into usr.sbin/syslogd.c but it seems easy enough to extend it to allow ' ' as well. If we stay with tabs only, should the manpage emphasize "not spaces"? Also, making the mistake I made results in the line just being ignored; the log file is never written to. Should the starting syslogd complain about lines with space but not tabs?
Re: MariaDB and OpenBSD
The relevant code is in the client library and if I remember correctly is just used for asynchronous access functions. It won't affect your use of the server on Linux x86/x86_64. The relevant code is written in assembler for amd64/i386 and for other arches it falls back to using ucontext.h functions specified by an old version of posix which were never implemented on OpenBSD. They were marked 'obsokescent' in newer posix due to a dependency on an obsolescent C language feature (see 'rationale' in http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html) so can't be used in strictly posix-conforming software. They aren't widely used (I've only seen it in mariadb and powerdns-recursor) and unlikely to be added to OpenBSD. (For some uses, boost's context library might be an alternative, though I'm unsure about arch support). Bogdan Andu wrote: > > >maybe the fact that mariadb packages built correctly made me blind >enough to forget about any other package that might depend on mysql >and not mariadb libraries, and curiously enough p5-DBD-mysql was one of >them, which I modified it to suport mariadb > > >i was excited to use mariadb on my OpenBSD machines. > >i'll clean'em up and i'll switch back to mysql-5.1 packages. > >i have a some remaining bits, though left in the dark namely, >concerning that cryptic message from cvs : > >"Revert back to using MySQL 5.1 for the time being. MariaDB 5.5 >introduces >a new libmysqlclient non-blocking API which utilizes co-routines. The >X86 >specific GCC ASM co-routine support hid the fact that there was an >issue. >The only fallback code so far is POSIX user contexts which OpenBSD does >not >support." > >Please if someone can shed more light upon this comment, because it >seems that it has impact on linux also >and based on this comment, which seems to me very important, I want to >know if it is safe to run mariadb server >on linux also, as I do currently on an Ubuntu 13.04 linux x86_64 . > >Thank you all , for your comments, > >Bogdan > > > > From: Stuart Henderson >To: Bogdan Andu ; Bogdan Andu ; >"misc@openbsd.org" >Sent: Monday, July 1, 2013 10:01 AM >Subject: Re: MariaDB and OpenBSD > > >You are trying to use a -current ports tree on 5.3 which is not >supported and you can have various problems as a result of this. > >Also mariadb is not currently enabled in the ports tree. It is setup to >use mysql not mariadb so you're going to have to modify the port for >anything you're installing which uses mysql. > > >Bogdan Andu wrote: > >>on that machine I have imported mariadb in >>/usr/ports/databases/mariadb, via cvs, which compiled ok. >> >>The problem was with p5-DBD-mysql needed by mariadb-server-5.5.31p0, >>which refuses to install without it, and for that reason I had to >>generate a p5-DBD-mysql for mariadb, using the Makefile rev. 1.36 for >>that package. >> >>I took the following steps: >>1. checkout mariadb from cvs repository into >> /usr/ports/databases/mariadb >>2. compiled and generated the packages mariadb-server-5.5.31p0 and >>mariadb-client-5.5.31p0; >>3. removed mysql* packages (client and server) because of conflicts >>4. when tried to install newlly generated mariadb-server-5.5.31p0 it >>required >> p5-DBD-mysql, but p5-DBD-mysql depends on mysql-* stuff; >>5. I removed p5-DBD-mysql; >>6. I update the Makefile with rev. 1.36 in >>/usr/ports/databases/p5-DBD-mysql/Makefile to make it mariadb >>compatible >>7. I did sudo make install for p5-DBD-mysql >>8. sudo pkg_add mariadb-server-5.5.31p0 >>9. sudo pkg_add mariadb-client-5.5.31p0 >> >> >>both client and server are working, but programmaticaly I encountered >>that error which seems to be solved, as Stefan Sperling suggested, via >>LD_PRELOAD env, var. >> >>what I am doing wrong? >> >> >> >> >> From: Stuart Henderson >>To: misc@openbsd.org >>Sent: Saturday, June 29, 2013 1:19 AM >>Subject: Re: MariaDB and OpenBSD >> >> >>On 2013-06-28, Bogdan Andu wrote: >>> Hello, >>> >>> I have installed mariadb-server-5.5.31p0 and mariadb-client-5.5.31p0 >>> on an OpenBSD 5.3 amd64 machine. >> >>http://www.openbsd.org/faq/faq15.html#NoFun
Re: MariaDB and OpenBSD
maybe the fact that mariadb packages built correctly made me blind enough to forget about any other package that might depend on mysql and not mariadb libraries, and curiously enough p5-DBD-mysql was one of them, which I modified it to suport mariadb i was excited to use mariadb on my OpenBSD machines. i'll clean'em up and i'll switch back to mysql-5.1 packages. i have a some remaining bits, though left in the dark namely, concerning that cryptic message from cvs : "Revert back to using MySQL 5.1 for the time being. MariaDB 5.5 introduces a new libmysqlclient non-blocking API which utilizes co-routines. The X86 specific GCC ASM co-routine support hid the fact that there was an issue. The only fallback code so far is POSIX user contexts which OpenBSD does not support." Please if someone can shed more light upon this comment, because it seems that it has impact on linux also and based on this comment, which seems to me very important, I want to know if it is safe to run mariadb server on linux also, as I do currently on an Ubuntu 13.04 linux x86_64 . Thank you all , for your comments, Bogdan From: Stuart Henderson To: Bogdan Andu ; Bogdan Andu ; "misc@openbsd.org" Sent: Monday, July 1, 2013 10:01 AM Subject: Re: MariaDB and OpenBSD You are trying to use a -current ports tree on 5.3 which is not supported and you can have various problems as a result of this. Also mariadb is not currently enabled in the ports tree. It is setup to use mysql not mariadb so you're going to have to modify the port for anything you're installing which uses mysql. Bogdan Andu wrote: >on that machine I have imported mariadb in >/usr/ports/databases/mariadb, via cvs, which compiled ok. > >The problem was with p5-DBD-mysql needed by mariadb-server-5.5.31p0, >which refuses to install without it, and for that reason I had to >generate a p5-DBD-mysql for mariadb, using the Makefile rev. 1.36 for >that package. > >I took the following steps: >1. checkout mariadb from cvs repository into > /usr/ports/databases/mariadb >2. compiled and generated the packages mariadb-server-5.5.31p0 and >mariadb-client-5.5.31p0; >3. removed mysql* packages (client and server) because of conflicts >4. when tried to install newlly generated mariadb-server-5.5.31p0 it >required > p5-DBD-mysql, but p5-DBD-mysql depends on mysql-* stuff; >5. I removed p5-DBD-mysql; >6. I update the Makefile with rev. 1.36 in >/usr/ports/databases/p5-DBD-mysql/Makefile to make it mariadb >compatible >7. I did sudo make install for p5-DBD-mysql >8. sudo pkg_add mariadb-server-5.5.31p0 >9. sudo pkg_add mariadb-client-5.5.31p0 > > >both client and server are working, but programmaticaly I encountered >that error which seems to be solved, as Stefan Sperling suggested, via >LD_PRELOAD env, var. > >what I am doing wrong? > > > > > From: Stuart Henderson >To: misc@openbsd.org >Sent: Saturday, June 29, 2013 1:19 AM >Subject: Re: MariaDB and OpenBSD > > >On 2013-06-28, Bogdan Andu wrote: >> Hello, >> >> I have installed mariadb-server-5.5.31p0 and mariadb-client-5.5.31p0 >> on an OpenBSD 5.3 amd64 machine. > >http://www.openbsd.org/faq/faq15.html#NoFun
Re: MariaDB and OpenBSD
You are trying to use a -current ports tree on 5.3 which is not supported and you can have various problems as a result of this. Also mariadb is not currently enabled in the ports tree. It is setup to use mysql not mariadb so you're going to have to modify the port for anything you're installing which uses mysql. Bogdan Andu wrote: >on that machine I have imported mariadb in >/usr/ports/databases/mariadb, via cvs, which compiled ok. > >The problem was with p5-DBD-mysql needed by mariadb-server-5.5.31p0, >which refuses to install without it, and for that reason I had to >generate a p5-DBD-mysql for mariadb, using the Makefile rev. 1.36 for >that package. > >I took the following steps: >1. checkout mariadb from cvs repository into > /usr/ports/databases/mariadb >2. compiled and generated the packages mariadb-server-5.5.31p0 and >mariadb-client-5.5.31p0; >3. removed mysql* packages (client and server) because of conflicts >4. when tried to install newlly generated mariadb-server-5.5.31p0 it >required > p5-DBD-mysql, but p5-DBD-mysql depends on mysql-* stuff; >5. I removed p5-DBD-mysql; >6. I update the Makefile with rev. 1.36 in >/usr/ports/databases/p5-DBD-mysql/Makefile to make it mariadb >compatible >7. I did sudo make install for p5-DBD-mysql >8. sudo pkg_add mariadb-server-5.5.31p0 >9. sudo pkg_add mariadb-client-5.5.31p0 > > >both client and server are working, but programmaticaly I encountered >that error which seems to be solved, as Stefan Sperling suggested, via >LD_PRELOAD env, var. > >what I am doing wrong? > > > > > From: Stuart Henderson >To: misc@openbsd.org >Sent: Saturday, June 29, 2013 1:19 AM >Subject: Re: MariaDB and OpenBSD > > >On 2013-06-28, Bogdan Andu wrote: >> Hello, >> >> I have installed mariadb-server-5.5.31p0 and mariadb-client-5.5.31p0 >> on an OpenBSD 5.3 amd64 machine. > >http://www.openbsd.org/faq/faq15.html#NoFun
