softraid crypto root with serial console?
Hello. I am trying to create a 'headless' setup using a softraid crypto root with serial console on OpenBSD 5.6-release amd64. I have everything installed and working just fine, except I'm having a problem getting the 'headless' part going. I followed the instructions in section 7.6 of the FAQ at http://www.openbsd.org/faq/faq7.html#SerCon I edited /etc/ttys to enable the getty for tty00. I added 'set tty com0' to /etc/boot.conf It doesn't seem to work though. The Passphrase: prompt is still output to pc0, not com0. If I enter a bogus password at the Passphrase: prompt on pc0 to get to a boot> prompt, I can enter 'set tty com0' after which I get a Passphrase: prompt on com0 and everything works fine. It seems like for some reason /etc/boot.conf is not being seen/used? I would guess it might have something to do with the softraid crypto root setup but I don't know. Is there a bit that needs flipping somewhere to get the serial console to work with crypto root? Any info or pointers on this would be greatly appreciated. Thanks. -- John Merriam
Re: softraid crypto root with serial console?
On Thu, 6 Nov 2014, Joel Sing wrote: On Thu, 6 Nov 2014, TJ wrote: On Wed, Nov 05, 2014 at 11:33:21PM -0500, Ted Unangst wrote: If you look in sys/arch/amd64/stand/libsa/bioscons.c you'll see two functions, pc_probe and com_probe, which set cn->cn_pri. You'll need to swap MIDPRI and LOWPRI and rebuild, then rerun installboot. Alternatively, you could make a small unencrypted "a" partition on the disk with just an /etc/boot.conf file that contains the following: set tty com0 boot sr0a:/bsd Then do the crypto softraid install to another partition and it should boot like you'd expect. See: http://permalink.gmane.org/gmane.os.openbsd.misc/206003 Thanks for that link, I searched and couldn't find anything. For now this is what I would recommend... Hmmm. Looking at the code, I'm going to guess the answer is no, but is it expected that this issue of changing the console with crypto root is going to be addressed soon (like maybe in one of the next 3 or 4 releases)? If it is expected that there will be a solution relatively soon I will change the code and recompile for now. If not, I'll go with the small a partition. Note that I am not expecting that it be fixed, just wondering if it is planned. It is a bit of a conundrum. I like not having a /boot hanging out there like they do in other OSes, but how to change the boot parameters without access to a filesystem... Thanks! -- John Merriam
pkg_add update checker?
Hello. I am trying to write a script to check for updates to the binary packages by checking the output of pkg_add then sending an e-mail if something is found. My very simple script is this: #!/bin/ksh NEWPKGS=`pkg_add -Iusx | grep -v "^quirks\-"` if [ "$NEWPKGS" != "" ]; then # send message to admin... fi Does that seem like it should work? Anyone know a better way to check for updates to packages automatically? I tried reading the code of pkg_add to see if there was a better way but I wasn't able to find one. Didn't find anything through searching either. This is one of those things I'd like to set up in a cron job to run once a day then forget about it until a message pops up in my Inbox so I'd like to get it right the first time. Thanks! -- John Merriam
Re: pkg_add update checker?
On Fri, 21 Nov 2014, Comète wrote: > 21 novembre 2014 23:00 "John Merriam" a écrit: >> Hello. I am trying to write a script to check for updates to the binary >> packages by checking the output of pkg_add then sending an e-mail if >> something is found. ... > > Maybe you're looking for this ? > http://www.mtier.org/index.php/solutions/apps/openup/ > > Morgan > Hmmm. Thanks for the suggestion. I'm looking for something much simpler though (KISS principle has been good to me in the past). My main question is is there something better than `pkg_add -Iusx | grep -v "^quirks\-"` to check for updates to packages? openup looks to be doing something similar for the update checking portion by using pkg_info output then fed to pkg_add to check for updates. Not sure why it wouldn't just use pkg_add to check for the updates. The code is also kinda odd to me. Seems overly complicated and looks to be doing some things that I'm not so sure I would want to be doing on my machines. Anyway, if there aren't any other tips or suggestions, I'll just go with what I have and adjust if I find issues down the road. Thanks! -- John Merriam
Re: pkg_add update checker?
On Sat, 22 Nov 2014, bodie wrote: > On 22.11.2014 03:40, John Merriam wrote: >> On Fri, 21 Nov 2014, Comète wrote: >>> 21 novembre 2014 23:00 "John Merriam" a écrit: >>>> Hello. I am trying to write a script to check for updates to the binary >>>> packages by checking the output of pkg_add then sending an e-mail if >>>> something is found. ... >>> >>> Maybe you're looking for this ? >>> http://www.mtier.org/index.php/solutions/apps/openup/ >>> >>> Morgan >>> >> >> Hmmm. Thanks for the suggestion. I'm looking for something much simpler >> though (KISS principle has been good to me in the past). My main question >> is is there something better than `pkg_add -Iusx | grep -v "^quirks\-"` to >> check for updates to packages? > > You did not mention what version of OpenBSD you are using. Is it -release, > -stable or -current? At the moment I am on 5.6-release > For -release, -stable there are hardly any updates during 6 months period > so checking it everyday is quite pointless. For -current you need to follow > at least current.html and mirrors for new snapshots eg. and what's most > important > you must keep system in sync so you will be doing update of packages in any > case no matter how much of them updated. Looking back at the past couple releases it looks like there haven't been any updates to the binary packages at all? That seems kind of surprising to me. I'm used to running Debian stable where there are lots of package updates. Debian almost never updates anything in their stable releases unless there is a security issue, but still there are lots of updates. > So for -release/-stable your script is of use (plus security.html of course), > but doesn't need to be run everyday for sure. In organizations you will need > to have some release/patching calendar anyway to make managers happy and they > will not allow patching window quite often so something like once a month > like Microsoft or quaterly will be more then enough. > > About -current...new packages most of the time mean that you need new OS too > so you will have process for complete upgrade anyway in place and then your > script may fill mailbox daily with a lot of info which soon no one will read > because it's simply not only info created out of one machine by cron and all > other stuff like log monitors and such. > > >> >> openup looks to be doing something similar for the update checking >> portion by using pkg_info output then fed to pkg_add to check for updates. >> Not sure why it wouldn't just use pkg_add to check for the updates. The >> code is also kinda odd to me. Seems overly complicated and looks to be >> doing some things that I'm not so sure I would want to be doing on my >> machines. >> >> Anyway, if there aren't any other tips or suggestions, I'll just go with >> what I have and adjust if I find issues down the road. Thanks! Please forgive my ignorance on this issue since the last time I used OpenBSD pkg_add didn't have all this update checking stuff. I used binary packages because that's what the FAQ recommends. Would I be better off using ports instead? Are the ports updated more frequently? I really like the stability of -release (or -stable I guess) but I don't want to lose out on security updates to the packages/ports... -- John Merriam
Re: pkg_add update checker?
Thank you all for your replies. It helped me to figure out what is going on. I think for this project I will see how it goes with -stable and -stable ports. For other projects I will definitely try -current. Others I shouldn't need anything more than -release + patches. On 11/22/2014 10:38 PM, Артур Истомин wrote: p.s. It is bad recommendation in FAQ, because it always confuse newcomers, when they come for security and find out that there is no update for stable repo. Being a newcomer (or newcomebacker?), I would agree with that. I read a lot of the FAQ and other support pages before I even downloaded 5.5-release to test it out. I think what I must have done is read '15.4.6 - What should I use: packages or ports?' before I read the rest of FAQ 15. By doing that I must have skimmed/skipped over 15.3 and missed the key section '15.3.10 - Security updates' which does describe the situation. Anyway, thanks again! -- John Merriam
Apache2 - intermittent ssl_error_rx_record_too_long
Hello. I am experiencing a strange problem with Apache 2.2.27p4 on OpenBSD 5.6-stable amd64. I am _intermittently_ getting this error: SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) in Firefox 31.3.0esr (both Linux and Windows clients) when accessing my server via HTTPS. I am not seeing errors pop up in other browsers but I am seeing strange things in IE11 and Chromium where things seem to not always load over HTTPS. The Qualsys SSL Server Test website also reports errors accessing my server sometimes when I have run tests against it using their tool. What is very strange is that it is intermittent. Things seem to work then click a link or reload a page and the error pops up. I have done much searching and fiddled with various settings and have not been able to find a solution so far. I do not think it is a network problem (unless it is a hardware vs driver issue for the NIC in the server) since I have tested with pf disabled on the server with a client on the same ethernet segment and the problem is still there. I am also pretty confident in the Apache configuration. It was mostly transferred from a tried and true Apache 2.0.65 config. Not by just dumping the old config in place, but by using what was installed by the apache-httpd package as a base then carefully merging in my changes. Nothing is showing up in the Apache error_logs. I was also able to test with two different certificates. My old certificate was up for renewal and it was also SHA1. So I renewed my certificate at the CA today (and upped it to SHA256). No change. What is different about my certificate compared to what most other people are probably doing is that my certificate is a wildcard certificate (valid for *.example.com and example.com). I have never had a problem with these wildcard certificates in the past. But I don't think I've ever tried to use them with Apache beyond 2.0.X though... Anyway, I'm prepared to dive deeper but the attack surface is huge. So many possible places where this problem could be residing. Has anyone here ever run in to this before? Anyone have any suggestions/hints/hunches/etc. as to where to start looking? Thanks! -- John Merriam
Re: Apache2 - intermittent ssl_error_rx_record_too_long
On 12/4/2014 8:46 PM, John Merriam wrote: Hello. I am experiencing a strange problem with Apache 2.2.27p4 on OpenBSD 5.6-stable amd64. I am _intermittently_ getting this error: SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) in Firefox 31.3.0esr (both Linux and Windows clients) when accessing my server via HTTPS. I am not seeing errors pop up in other browsers but I am seeing strange things in IE11 and Chromium where things seem to not always load over HTTPS. The Qualsys SSL Server Test website also reports errors accessing my server sometimes when I have run tests against it using their tool. What is very strange is that it is intermittent. Things seem to work then click a link or reload a page and the error pops up. *snip* I seem to have stopped the odd Apache behavior. Still not sure why it was a problem though. I was able to observe that Apache 2.2 was occasionally deciding it didn't want the use the appropriate protocol on the proper port. I was able to get it to occasionally speak HTTP on port 443. I was also able to occasionally get it to speak HTTPS on port 80. I found that extremely strange. At the start of this adventure I had the following pertinent configuration set: /etc/apache2/httpd2.conf Listen 80 ... ... Include /etc/apache2/extra/httpd-ssl.conf /etc/apache2/extra/httpd-ssl.conf - Listen 443 ... ... At the end, it looked like the following: /etc/apache2/httpd2.conf Listen 1.2.3.4:80 http Listen 1.2.3.5:80 http ... ... Include /etc/apache2/extra/httpd-ssl.conf /etc/apache2/extra/httpd-ssl.conf - Listen 1.2.3.4:443 https Listen 1.2.3.5:443 https ... ... I had to specify multiple Listen directives for each IP. I would guess that specifying the protocol in the Listen directives might not be necessary to fix this, but at this point, I'll leave it... The Apache docs don't seem to indicate that using Listen directives like that should have been necessary. Very strange to me. If I have the time, I'll see if I can figure out exactly what the issue was here. I think I might have an idea of what was going on and it may not really be a bug in Apache but if it's not then the behavior should be documented by them somewhere. Anyway, at this point, I don't think this has much to do with OpenBSD specifically. So, sorry for the noise but I figured I should send the resolution that I found in case someone else runs in to this. -- John Merriam
Re: simple way to block one word domains?
On Tue, 9 Dec 2014, Ted Unangst wrote: > Curious if anyone knows a simple way to prevent resolution of one word > hostnames. Either via resolv.conf or unbound.conf. > > For example: > > athens:~> host android > android has address 127.0.53.53 > android mail is handled by 10 your-dns-needs-immediate-attention.android. > > I do not like this. > > athens:~> host bobo > Host bobo not found: 3(NXDOMAIN) > > This is much better. > > athens:~> host com > > This isn't great either. > > I realize this is how DNS works, but I also think it's something I > should be able to "fix" at a local level. The fact that anything and > everything can now be a TLD is pretty sneaky. If a DNS lookup has only > a single part, I would like to restrict it to the search domain. > I'm by no means a DNS expert but I've been dealing with it for a long time. The only thing I can think of to force one word hostnames to be resolved in the search domain exclusively would be to patch the resolver library. If you find an answer please do pass it along because I might be interested in putting that in place on a few machines. Probably the best solution would be a patch to the resolver library that adds an option to resolv.conf(5) that allows it to easily be turned on/off. The only question is would this break things? Maybe it would require a bypass list of TLDs in a file like /etc/resolv_tlds.conf? -- John Merriam j...@johnmerriam.net
Re: Hide VM data from customer
On Tue, 9 Dec 2014, Nathan Wheeler wrote: > Hi everyone, > > We use OpenBSD currently on physical hardware and manage it in our > customers location. We want the option to give out VMs to host on > customer premises and we'll still manage the VM (but not the VM > platform). > > The problem is not letting the customer access to our proprietary data > as they could easily mount the virtual hard drive somewhere else. The > obvious answer is disk encryption, but we can't require manual > intervention to enter a passphrase or to provide a key. > > I'm sure I'll have to settle with obfuscation, which I'm OK with, but > I'm curious if there is a good/best way to go about that. > > Is the only option to change things we need to hide into binaries? > Compile the kernel with a key to decrypt? > > I've taken a look at how other vendors do it like Juniper. With their > VM I can mount the boot partitions, but they only have boot > information and the kernel. I can't mount the extended partitions, > they don't even seem to be formatted with a filesystem. My guess is > they compile the kernel with a key or something, but its just a guess. > > Thanks for any advice! > > Nate > You said that you are already letting your proprietary data out in the wild since you have machines on customer premises with this data in unencrypted form. If it moves from a physical machine to a virtual one it is true that it makes it easier for someone to access it but not that much easier. Anyway, the way I see it, the only way to keep someone from accessing your data is encryption. Obfuscation alone will make it harder but not impossible. To avoid manual intervention when using encryption you need a way to get the key/passphrase to the machine/application. If you were using application/file level encryption, you could compile the key in to a binary application that would then work with the data. That is still obfucation to an extent because they could still decompile the binary and find your key. Another option I just thought of is if you coded your application that accesses the data to download (over an encrypted connection of course...) the key from a server that you control at your location that the application would then use to decrypt the data. If you wanted to use FDE without manual intervention you would need to modify the OS source to find the key somewhere (unallocated sectors at the end of the disk or between partitions?) that it could access before it tries to decrypt the partition. Obfuscation again. But pretty well obfuscated. Another thing you could do is have a separate partition that is not the boot partition (like /data) that is encrypted and have the boot scripts decrypt and mount the partition. You would need to cary around the passphrase/key on the unencrypted boot partition though. Obfuscaction again (but maybe you could combine this with downloading the key/pass from a server of yours?). The only thing I mentioned that doesn't involve obfuscation or manual intervention is coding an/your application that will download the key from a server to decrypt the data that has been encrypted. You would need to use something like HTTPS with username/password or SCP to transfer the key. The server serving the key should have access to it restricted by IP. Oh, but wait, they could still get the key if they decompile the program that downloads the key and do exactly what it does. Hmmm, still obfuscation I guess. Oh, and no matter what you do, they could always dump the RAM from your VM instance and get your data from there after it's been decrypted. So, yeah, no really good answer that I know of. I'm not an expert in areas such as this, but this is the way I see it. Your best bet is probably encryption combined with some good obfuscation as to what the key is/where to get it. Not moving your data to a VM would make some of these attacks harder but not impossible for a determined attacker. -- John Merriam
Re: simple way to block one word domains?
On 2014-12-09 11:33, John Merriam wrote:
On Tue, 9 Dec 2014, Ted Unangst wrote:
Curious if anyone knows a simple way to prevent resolution of one word
hostnames. Either via resolv.conf or unbound.conf.
*snip*
I'm by no means a DNS expert but I've been dealing with it for a long
time. The only thing I can think of to force one word hostnames to be
resolved in the search domain exclusively would be to patch the
resolver
library.
*snip*
This TLD explosion bothers me too. After thinking about it for a while
I came up with a solution that works for me. It does not involve
patching the resolver library as I mentioned before. It would be nice
to patch the resolver library because it would guarantee that your
systems wouldn't look up any of the crummy TLDs that you don't want them
to regardless of what DNS servers they're using. But I decided against
doing that because I figured it would be a controversial issue and it
probably wouldn't be accepted for inclusion in OpenBSD and carrying
around local patches isn't fun.
So, I quickly hacked together a dirty little script I call tldblocker.
It downloads the list of TLDs from IANA then removes the TLDs you want
to allow then uses the trimmed TLD list that contains the TLDs you want
to block to create a file that can be included in your DNS server config
that points the blocked TLDs at an empty zone file. This isn't exactly
what you were looking for but I am sending it along in case you find it
useful.
Here is the script:
#!/usr/bin/perl
# tldblocker v0.0.1
# Use this at your own risk...
# You should check what this thing is really doing at least
occasionally.
$tldurl = "http://data.iana.org/TLD/tlds-alpha-by-domain.txt";;
$adminaddress = "admin\@example.com";
$allowedfile = "/usr/local/var/tldblocker/tldblocker.allowedtlds";
$tldfile = "/usr/local/var/tldblocker/tldblocker.alltlds";
$tempfile = "/tmp/tldblocker.alltlds.temp";
$md5cmd = "/bin/md5 -q";
$downloadcmd = "/usr/local/bin/wget -q -O " . $tempfile . " " . $tldurl;
$outfile = "/var/named/namedb/named.zones.tldblocker";
$emptyzonefile = "namedb/empty.zone";
$namedrestartcmd = "/etc/rc.d/isc_named restart";
$smprog = "/usr/sbin/sendmail";
if (!-s $allowedfile) {
# I think we should allow at least some TLDs!
die "I could not find the allowed TLDs file!\n";
}
system $downloadcmd;
# Did download command exit with status 0?
if ($? != 0) {
# Download command failed, send message to admin...
system "echo -e \"Subject: tldblocker failed to download TLD
file!\\n\\ntldblocker failed to download the TLD file from the following
URL:\\n\\n$tldurl\\n\\nGo take a look.\" | $smprog $adminaddress";
exit 1;
}
# Do a basic sanity check on the downloaded file
open TLDFH, "<$tempfile";
@tldsin = ;
close TLDFH;
$quickcheck = join "", @tldsin;
if (($tldsin[0] !~ /^# Version /) ||
($quickcheck !~ /\nCOM\n/i) ||
($quickcheck !~ /\nNET\n/i) ||
($quickcheck !~ /\nORG\n/i) ||
($quickcheck !~ /\nEDU\n/i) ||
($quickcheck !~ /\nGOV\n/i) ||
($quickcheck !~ /\nMIL\n/i) ||
($quickcheck !~ /\nINT\n/i) ||
($quickcheck !~ /\nARPA\n/i)) {
# This doesn't look right, send message to admin
system "echo -e \"Subject: tldblocker dowloaded TLD file failed sanity
check!\\n\\nThe TLD file downloaded by tldblocker from the following
URL:\\n\\n$tldurl\\n\\nfailed the basic sanity check. Go take a look.\"
| $smprog $adminaddress";
exit 1;
}
undef $quickcheck;
# See if we need to do anything
$oldtldmd5 = `$md5cmd $tldfile`;
$newtldmd5 = `$md5cmd $tempfile`;
$oldallowedmd5 = `cat $allowedfile.MD5`;
$newallowedmd5 = `$md5cmd $allowedfile`;
$updateneeded = 0;
$dontunlink = 0;
if ($oldtldmd5 ne $newtldmd5) {
$updateneeded = 1;
system "mv $tempfile $tldfile";
$dontunlink = 1;
}
if ($oldallowedmd5 ne $newallowedmd5) {
$updateneeded = 1;
system "$md5cmd $allowedfile > $allowedfile.MD5";
}
# Update if necessary
if ($updateneeded == 1) {
open ALLOWEDFH, "<$allowedfile";
@allowed = ;
close ALLOWEDFH;
$i = 0;
foreach $i (0..$#allowed) {
chomp $allowed[$i];
}
@blocktlds = @tldsin;
undef @tldsin;
splice @blocktlds, 0, 1;
$c = 0;
$blocktldsend = $#blocktlds;
while ($c <= $blocktldsend) {
chomp $blocktlds[$c];
if ($blocktlds[$c] =~ /^([A-Za-z0-9\-])+$/) {
$i = 0;
foreach $i (0..$#allowed) {
if ($blocktlds[$c] =~ /^$allowed[$i]$/i) {
splice @blocktlds, $c, 1;
$c--;
$blocktldsend--;
last;
}
}
} else {
# Probably a comment?
splice @blocktlds, $c, 1;
$c--;
$blocktldsend--;
}
$c++;
}
if (($#blocktlds >= 0) && ($blocktlds[0] ne &quo
Re: [probably solved] Re: Openbsd broke my hard drive twice! Getting frustrated
On Tue, 23 Dec 2014, Henrique Lengler wrote: > I figured that my BIOS have a old firmware from 2013. So I decided to update > it. > At least this my motherboard did good, I easily updated the firmware by > plugging > a USB with the new firmware. > Then It rebooted and yes, it worked as it should. Booted normally with the HDD > sata > connected. I cannot get satisfied yet, I will install a OS and see if it will > still > working. > I'm in doubt about try openBSD again, I'm afraid everything could happen > again. > > Also is there a explanation to this shitty behavior? My motherboard acted like > having a > short circuit, making everything stop working because a bad formatted HDD, > this is a > really unexpected behavior, which made me think the problem was openBSD. > > By now, thanks for helping. > I expect don't need to post anything more here. > > Regards, > -- > Henrique Lengler > > I would guess that you hit a bug (or multiple bugs) in the BIOS. Probably something related to UFEI. I generally try to update the BIOS on my machines when I'm starting over from scratch with them. When I recently changed my home server to OpenBSD I upgraded the motherboard BIOS before starting the process even though I was not experiencing any problems with the previous BIOS with Linux installed on the machine. I don't have any UFEI machines except at work (thank goodness). It doesn't surprise me that a UFEI BIOS would be buggy and produce behavior like that. -- John Merriam
Re: Getting the right image, to install via USB
On Tue, 23 Dec 2014, Henrique Lengler wrote: > Hi, > > I want to install openbsd on my computer via a USB, since I don't > have a unused CD. > > I'm in doubt about what image should I download and how can I record > it to a USB using windows. > > Could someone please help me? > -- > Henrique Lengler > > As mentioned in section 4.3 of the OpenBSD FAQ, you would want the install56.fs file if you want to write it to a USB drive. To write it to a USB drive in Windows you would need a program like dd to do it. There is a Windows dd program here: http://www.chrysocome.net/dd I have never used it before. Based on a quick scan of that web page I would say you should be very careful what arguments you pass to that dd program at chrysocome.net since it looks like it would be easy to wipe out the hard drive of the Windows machine you are using to prepare the USB drive. There might or might not be a better alternative to the dd program at chrysocome.net out there on the internet. -- John Merriam
OpenBSD + OptiPlex 320 = frozen clock?
0x10: apic 8 int 22, address 00:40:f4:6c:99:b2 rlphy0 at rl0 phy 0: RTL internal PHY bce0 at pci2 dev 9 function 0 "Broadcom BCM4401B1" rev 0x02: apic 8 int 21, address 00:1d:09:16:ca:2e bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 "ATI OHCI root hub" rev 1.00/1.00 addr 1 usb2 at ohci1: USB revision 1.0 uhub2 at usb2 "ATI OHCI root hub" rev 1.00/1.00 addr 1 usb3 at ohci2: USB revision 1.0 uhub3 at usb3 "ATI OHCI root hub" rev 1.00/1.00 addr 1 usb4 at ohci3: USB revision 1.0 uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1 usb5 at ohci4: USB revision 1.0 uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 uhidev0 at uhub1 port 1 configuration 1 interface 0 "Logitech Optical USB Mouse" rev 2.00/3.40 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 uhub6 at uhub1 port 2 "Dell Dell USB Keyboard Hub" rev 1.10/48.01 addr 3 uhidev1 at uhub6 port 1 configuration 1 interface 0 "Dell Dell USB Keyboard Hub" rev 1.10/48.00 addr 4 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 uhidev2 at uhub6 port 1 configuration 1 interface 1 "Dell Dell USB Keyboard Hub" rev 1.10/48.00 addr 4 uhidev2: iclass 3/0, 3 report ids uhid0 at uhidev2 reportid 1: input=1, output=0, feature=0 uhid1 at uhidev2 reportid 2: input=1, output=0, feature=0 uhid2 at uhidev2 reportid 3: input=3, output=0, feature=0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (387205e18729d3cc.a) swap on sd0b dump on sd0b drm: initializing kernel modesetting (RS400 0x1002:0x5A61 0x1028:0x01E5). radeondrm0: VRAM: 32M 0xCE00 - 0xCFFF (32M used) radeondrm0: GTT: 512M 0xA000 - 0xBFFF drm: PCIE GART of 512M enabled (table at 0xCCD8B000). error: [drm:pid0:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware "radeon-r300_cp" error: [drm:pid0:r100_cp_init] *ERROR* Failed to load firmware! error: [drm:pid0:rs400_startup] *ERROR* failed initializing CP (-2). error: [drm:pid0:rs400_init] *ERROR* Disabling GPU acceleration drm: radeon: cp finalized radeondrm0: 1280x1024 wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 wskbd1: connecting to wsdisplay0 wsdisplay0: screen 1-5 added (std, vt100 emulation) -- John Merriam
Re: OpenBSD + OptiPlex 320 = frozen clock?
On 1/2/2015 2:00 PM, Nathan Wheeler wrote: Try changing the value for the sysctl variable "kern.timecounter.hardware"? Its just a guess, but its helped me when I had problems with the clock before. On Fri, Jan 2, 2015 at 7:47 AM, John Merriam wrote: Hello. I have a strange issue with OpenBSD on my Dell OptiPlex 320. The clock doesn't move: # date; sleep 55; date Thu Jan 1 02:25:47 EST 2015 Thu Jan 1 02:25:47 EST 2015 I see the same behavior with 5.6-release amd64 and -current amd64. The clock works fine in Windows and Linux on this machine. I installed the December 27th snapshot on it so I can mess around with it and try to get it fixed. Has anyone seen this before? If not, any tips on what to try or where I should start looking in the code to try to figure out what's going on? Below is the dmesg: *snip* Thanks. I probably should have thought to look for a knob like that. The clock works fine with kern.timecounter.hardware set to either i8254 or acpitimer0 but not when it is set to acpihpet0 The OptiPlex 320 was designed and produced not long after HPET started showing up in PCs. I would guess the OptiPlex 320 has a buggy HPET. Since it isn't supported by Dell anymore, I doubt they would be interested in trying to fix it via a BIOS update if it would even be possible for them to fix it in the BIOS. Is it worth messing around with to try to get HPET working on the OptiPlex 320 in OpenBSD or would it be written off as buggy hardware? I guess that assumes it could work at all... Here's another question that I have after reading up on this stuff. Is it worth using the HPET or ACPI timers in OpenBSD for non desktop machines? Obviously it depends on one's particular situation but from my reading it sounds like the most common reason to want better timers is multimedia which is usually not something to worry about on most servers. -- John Merriam
Re: OpenBSD + OptiPlex 320 = frozen clock?
On Mon, 5 Jan 2015, Stuart Henderson wrote: > On 2015-01-03, John Merriam wrote: > > > > Is it worth messing around with to try to get HPET working on the > > OptiPlex 320 in OpenBSD or would it be written off as buggy hardware? I > > guess that assumes it could work at all... > > Probably write off as buggy. Some automated way to detect that it's buggy > might be nice though... > > > Here's another question that I have after reading up on this stuff. Is > > it worth using the HPET or ACPI timers in OpenBSD for non desktop > > machines? Obviously it depends on one's particular situation but from > > my reading it sounds like the most common reason to want better timers > > is multimedia which is usually not something to worry about on most servers. > > Some programs call gettimeofday() a *lot*, and there's quite a difference in > performance between the various clock sources. > > On my laptop, timing a loop of 5,000,000 gettimeofday() calls: > > acpihpet: 0m3.29s > acpitimer: 0m10.49s > i8254: 0m21.44s > > (I wonder how an ITSC-based timecounter would look...) > I guess I'll stick with the HPET or ACPI timers which is what I was leaning towards anyway (I figured they must be the default for a reason). I wasn't able to draw any conclusions about which timer might be "best" based on what I read. Thanks! -- John Merriam
Updating Ports Question
Hello. I am running 5.6-stable amd64 and using the -stable ports. I must be doing something wrong when I am updating ports. I do: cd /usr/ports cvs -q up -rOPENBSD_5_6 -Pd infrastructure/bin/out-of-date and I see: Collecting installed packages: ok Collecting port versions: ok Collecting port signatures: ok Outdated ports: devel/quirks # always-update -> quirks-2.9 lang/php/5.4,-main,ap2 # 5.4.35 -> 5.4.36 lang/php/5.4,-mcrypt # 5.4.35 -> 5.4.36 lang/php/5.4,-pdo_mysql# 5.4.35 -> 5.4.36 lang/php/5.4,-pspell # 5.4.35 -> 5.4.36 lang/php/5.4,-zip # 5.4.35 -> 5.4.36 mail/roundcubemail # @php-5.4.35,@php-mcrypt-5.4.35,@php-pspell-5.4.35,@php-zip-5.4.35 -> @php-5.4.36,@php-mcrypt-5.4.36,@php-pspell-5.4.36,@php-zip-5.4.36 www/pear,-utils# @php-5.4.35 -> @php-5.4.36 so I do: cd lang/php/5.4 env FLAVOR="ap2" SUBPACKAGE="-main" make update (I would guess I probably don't need the env variables since it seems to be smart enough to update only what I have installed already but whatever) If I then do another /usr/ports/infrastructure/bin/out-of-date I still see this: Collecting installed packages: ok Collecting port versions: ok Collecting port signatures: ok Outdated ports: devel/quirks # always-update -> quirks-2.9 mail/roundcubemail # @php-5.4.35,@php-mcrypt-5.4.35,@php-pspell-5.4.35,@php-zip-5.4.35 -> @php-5.4.36,@php-mcrypt-5.4.36,@php-pspell-5.4.36,@php-zip-5.4.36 www/pear,-utils# @php-5.4.35 -> @php-5.4.36 Why do roundcubemail and pear still show up there when php has been updated? Trying to run a make update for either of them does nothing. I must be doing something wrong or missing another step I should be doing but I'm not sure what it is. I haven't found any answers through searching. Any suggestions would be appreciated. Thanks! PS - devel/quirks is always there and I am assuming it should be? -- John Merriam
Re: Updating Ports Question
On 1/5/2015 7:46 PM, Stuart Henderson wrote: On 2015-01-05, trondd wrote: On Mon, Jan 5, 2015 at 4:00 PM, John Merriam wrote: If I then do another /usr/ports/infrastructure/bin/out-of-date I still see this: Collecting installed packages: ok Collecting port versions: ok Collecting port signatures: ok Outdated ports: devel/quirks # always-update -> quirks-2.9 mail/roundcubemail # @php-5.4.35,@php-mcrypt-5.4.35,@php-pspell-5.4.35,@php-zip-5.4.35 -> @php-5.4.36,@php-mcrypt-5.4.36,@php-pspell-5.4.36,@php-zip-5.4.36 www/pear,-utils# @php-5.4.35 -> @php-5.4.36 Why do roundcubemail and pear still show up there when php has been updated? Trying to run a make update for either of them does nothing. Those are showing up because they were built against the older version of PHP and PHP modules. Those packages themselves did not change but you need to rebuild them. Ports won't rebuild a package you already have built. There might be a way to override that which I don't know about, but you can just find and delete them from /usr/ports/packages/* then 'make reinstall'. Or just ignore the output from out-of-date, there won't be any real change for these other packages. So long as I'm not doing something incorrectly, I think I'll go with option 2 and just ignore it since it's PHP, not like a library or something. Thanks again! -- John Merriam
Re: man -m: Bad argument
On Thu, 12 Feb 2015, Jan Stary wrote: > I have some man pages installed in $HOME/man > so I ugment my manpath like this in my ~/.shrc > > test -d $HOME/man && alias man="man -m $HOME/man" > > Now man(1) complains saying > > $ man ls > man: -m/home/hans/man: Bad argument > > Using "$HOME/man/" or "$HOME/man:" results in the same. > > Am I missing something obvious? > > Jan > What does it show when you run the alias command with no arguments to display your current aliases? I noticed that in the error message there is no space between -m and the path. That seems a bit odd. Your `test -d $HOME/man && alias man="man -m $HOME/man"` works fine for me in ksh when I put it in a .profile on 5.6 -stable. -- John Merriam
Re: man -m: Bad argument
On Thu, 12 Feb 2015, Jan Stary wrote: > On Feb 12 11:12:46, j...@johnmerriam.net wrote: > > On 2015-02-12 10:50, Jan Stary wrote: > > >On Feb 12 10:15:08, j...@johnmerriam.net wrote: > > >>What does it show when you run the alias command with no arguments to > > >>display your current aliases? > > >> > > >>I noticed that in the error message there is no space between -m and the > > >>path. That seems a bit odd. > > > > > >$ alias > > >autoload='typeset -fu' > > >diff='diff -Nup' > > >functions='typeset -f' > > >hash='alias -t' > > >history='fc -l' > > >integer='typeset -i' > > >ll='ls -lAp' > > >local=typeset > > >login='exec login' > > >ls='ls -p' > > >man='man -m /home/hans/man' > > >nohup='nohup ' > > >pdftops='pdftops -paper A4' > > >r='fc -e -' > > >stop='kill -STOP' > > >type='whence -v' > > > > > > > > >In particular, the space is there, as specified in the alias command. > > >But the problem is probably not in the aliases: > > > > > >$ unalias man > > >$ man -m ~/man ls > > >man: -m/home/hans/man: Bad argument > > > > > > Jan > > > > I would assume it would cause you more problems than just man if it were the > > case, but, if you do a `vis /etc/passwd`, are there any funny characters in > > the home directory for your username? Just a thought since that space > > between -m and the path seems to disappear in the error. > > No. > > > If you leave out -m /path and just run `man ls`, does that work? > > With man unaliased, it works just fine. > With 'man -m ~/man', or with man aliased to that, > 'man ls' gave me the error above. > > > Also, which version of OpenBSD are you running on this machine? > > 5.6 or -current? > > current/amd64 > > Jan > > Hmmm. There was one small change to man.c on January 16th but it doesn't look like that should be the problem I wouldn't think. Previous change was back in 2013. It is also possible it is something funny with shell expansion or something. Which shell are you using? I just blew away my -current machine the other day. I don't have -current running any more so I can't try to duplicate it for you. If no one else answers the thread on misc I would recommend sumitting a bug with sendbug. -- John Merriam
Re: Patching X in BASE without X
On 3/7/2015 2:08 PM, Andrew Lester wrote: Hi All, This should be a very easy question. A while back I had questioned when running a system with BASE whether it is fine to skip applying patches not applicable to my system’s uses, and whether they can be done out of order. The response I got was mixed, but it seems the safest bet is to apply patches in order, and apply all patches. This being the case, will it in any way harm or cause problems on a system if I apply patches for X, if I do not have X installed? Kind regards, Andrew Lester The result of patching xenocara according to the instructions in the patch file is that you would then have at least that portion of X installed. In the case of the latest errata 16 for 5.6, it would mean that you would end up with the X server binaries installed but not the rest of X. If you truly did not install the X packages when you installed OpenBSD I would recommend not patching X. -- John Merriam
Re: Broadcom NIC issues
On Fri, 13 Mar 2015, Miguel Barbosa Gon?alves wrote: > Hi! > > I recently installed OpenBSD 5.6 on an amd64 platform. Everything went > smoothly. After installation, at the first boot, OpenBSD updated the > firmware of some devices. I found this strange... > > I had to reinstall this machine with CentOS and now the NIC does not work. > > I reinstalled OpenBSD again and it works. I tried to reflash the NIC's > firmware and the installer does not recognize the NIC. At the moment, the > machine only works with OpenBSD... > > What did OpenBSD do and how can I revert this? > Maybe a silly question, but have you power cycled (turn computer completely off then back on) the machine between running OpenBSD and running CentOS? If you haven't tried a power cycle and it works, that won't solve what the problem is but might at least allow you to run CentOS again. I have seen strange things happen in the past when switching between OSes but that was a very long time ago. -- John Merriam
Re: Broadcom NIC issues
On Fri, 13 Mar 2015, Miguel Barbosa Gon?alves wrote: > 2015-03-13 15:56 GMT+00:00 John Merriam : > On Fri, 13 Mar 2015, Miguel Barbosa Gon?alves wrote: > > Hi! > > > > I recently installed OpenBSD 5.6 on an amd64 platform. > Everything went > > smoothly. After installation, at the first boot, OpenBSD > updated the > > firmware of some devices. I found this strange... > > > > I had to reinstall this machine with CentOS and now the NIC > does not work. > > > > I reinstalled OpenBSD again and it works. I tried to reflash > the NIC's > > firmware and the installer does not recognize the NIC. At the > moment, the > > machine only works with OpenBSD... > > > > What did OpenBSD do and how can I revert this? > > > > Maybe a silly question, but have you power cycled (turn computer > completely off then back on) the machine between running OpenBSD > and > running CentOS? If you haven't tried a power cycle and it > works, that > won't solve what the problem is but might at least allow you to > run CentOS > again. > > > Hi John! > > Yes, I completely removed the power cable from the machine. I even tried > running an older version of CentOS and it did not work. > > I am completely clueless... > > Thanks! > I would recommend replying to this thread with the output from the dmesg and pcidump -v commands under OpenBSD. That may give someone here a clue as to what your problem may be. If you don't get any replies a few days after posting the output of those commands then you could try submitting a bug report using the sendbug program under OpenBSD. -- John Merriam
Re: Executable signing - a proposal
On Tue, 31 Mar 2015, Gareth Nelson wrote: > Before anyone says it, i'd be more than willing to work on the code for > this myself but would like feedback on the idea. > > Essentially as follows: > > 1 - A sysctl variable stores a public key that can only be written to once > at startup > 2 - All executables on the system must be signed with that public key > 3 - Any executable not signed is essentially chmod -x > > Of course that's the simple basic idea, there are obvious performance > issues to consider and this system would have to be optional, but for truly > paranoid installs it could be a wonderful feature. > > More complex policies are easily imagined, but for a first version, simply > refusing to run executables without signing seems worthwhile. > > The performance issues could be partly addressed by only signing hashes of > the executables, the unsigned hashes would be stored all in one file that > is supplied with the install sets and signed the first time this feature is > enabled. Signing can take place on another machine and only the signature > file copied over, or signing can take place locally with the private key > later removed - or simply left in place for slightly lower levels of > security. > It sounds to me like you are describing a type of host-based intrusion detection/protection. Integrating host-based intrustion detection in to an OS kernel could be interesting. The issue is that to turn it in to a protection instead of just detection system would probably slow things down too much since it would need to run some sort of check on each binary before it is executed. Some people might really want something like this. I think the issue is that not enough people would be willing to accept the large slow down that would result. So, you probably won't end up with enough interested people needed to gain any momentum. And, as others have mentioned, it will only protect against certain attacks, and determined attackers will be able to get around it. -- John Merriam
Re: differences between pk_add -u and building from source at stable
On 4/1/2015 4:16 PM, Joel Rees wrote: Should there be a difference if I haven't botched the source tree for /usr/ports at some point? firefox --version tells me Mozilla Firefox 31.0 (It also gives a warning about size mismatch in a couple of c++ libraries and says I should relink the program, which is part of the message it sends to the console every time I run it. I'vd been ignoring that message.) And pkg_add -u firefox just talks to itself, then says quirks-2.9 signed on 2014-08-02T11:06:132 but cd /usr/ports/www/firefox-esr make -n tells me lock=firefox-esr-31.5.3 Hello. I had similar issues figuring this out when I started using OpenBSD again recently. If you are running -stable, the packages available from pkg_add are -release packages. From what others have said, the -release packages usually do not receive updates. To use -stable packages (which do receive updates via CVS), you must use ports and compile them from the ports tree. Obviously this is subject to change at any time but as far as I know that is still the situation. I don't mind using ports instead of packages myself. But, I haven't tried OpenBSD on the desktop yet (routers/firewalls and servers so far). Compiling huge stuff that updates often like Firefox could be kind of a pain I would guess. -- John Merriam
Re: differences between pk_add -u and building from source at stable
On Thu, 2 Apr 2015, Kevin Chadwick wrote: > On Wed, 01 Apr 2015 22:34:06 -0400 > John Merriam wrote: > > > I don't mind using ports instead of packages myself. But, I haven't > > tried OpenBSD on the desktop yet (routers/firewalls and servers so far). > > Compiling huge stuff that updates often like Firefox could be kind of > > a pain I would guess. > > Have you checked out mtier.org's stable packages support? > Yes, I have. It sounds nice. I'm a bit to paranoid though so I don't want to trust that additional layer/entity that I would have to in order to use their stuff. -- John Merriam
Re: What happens to OpenBSD when Secure Boot becomes manditory?
On Thu, 2 Apr 2015, Steve Litt wrote: > Hi all, > > What happens to OpenBSD when Secure Boot becomes manditory? > > > http://www.pcworld.com/article/2901262/microsoft-tightens-windows-10s-secure-boot-screws-where-does-that-leave-linux.html > > http://www.pcworld.com/article/2900536/windows-10s-secure-boot-requirement-could-make-installing-linux-a-big-headache.html > > http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secure-boot-alt-os-lock-out-a-reality/ > > http://news.thewindowsclub.com/microsoft-secure-boot-linux-75539/ > > http://www.extremetech.com/extreme/201722-linuxs-worst-case-scenario-microsoft-makes-secure-boot-mandatory-locks-out-other-operating-systems > > http://www.techradar.com/us/news/software/operating-systems/microsoft-s-windows-10-secure-boot-ruling-spells-trouble-for-linux-lovers-dual-booters-1289096 > > SteveT > > Steve Litt* http://www.troubleshooters.com/ > Troubleshooting Training * Human Performance > The people that want to run OpenBSD or any other OS that doesn't support it don't buy that junk? I think the more interesting question is, if secure boot ever did become 'mandatory', what would it do to the used computer equipment market? I have a feeling that there will be alternatives to secure boot for a while if not forever. I for one will never buy anything that is secure boot only unless the 'secure boot' is something that I have complete control over. I would rather use a typewriter... -- John Merriam
Re: Tips & tricks about using mysql under OpenBSD
On Fri, 3 Apr 2015, C.L. Martinez wrote: > On 04/01/2015 12:51 PM, C.L. Martinez wrote: > > Hi all, > > > > In the following weeks, I need to install a syslog collector server > > using mysql as a backend to store all logs (and I would like to use > > OpenBSD 5.7 to accomplish that). > > > > I expect +/- 5k-6k EPS from our servers (unix, linux, windows). As a > > syslog process I will use syslog-ng or rsyslog. But my question is about > > using mysql under OpenBSD. > > > > Due to the log volume, I will need to do, probably, some type of > > "tuning" in mysql side. > > > > Somebody uses mysql in production environments with a respectable > > amount of inserts under OpenBSD? Tips & tricks about what options to use > > under fstab where mysql stores all data, memory limits, etc? > > > > Thanks. > > Please, any inputs? > I don't see why running MySQL on OpenBSD would be much different than on any other OS? Set your settings in the MySQL config like you would on any other OS. Then look at the mount man page and see if there is anything there that you might want to change (my guess would be no...). I do have the following in my /etc/login.conf: mysqld:\ :openfiles-cur=1024:\ :openfiles-max=2048:\ :tc=daemon: which I got from the mysql-* file in /usr/local/share/doc/pkg-readmes It's possible there might be more interesting things to mess with in login.conf for MySQL but I'm guessing probably not more than those two openfiles settings. It sounds like this is a new project that you haven't done before? If you have done this with this amount of load before then you should have some guess as to how it will work. If not I would say start with the my-huge.cnf MySQL config and go from there. Try to do some testing, particularly try to simulate the load before you go to production. I'm thinking fast CPUs and fast disks will be your best friends on this project. -- John Merriam
Re: differences between pk_add -u and building from source at stable
On 4/5/2015 3:45 PM, Theo de Raadt wrote: Indeed. Kind of amusing. Entirely possible a mtier person commits to the port John is worried about. Like all of us they are volunteers... So John, who will you trust? And why will you trust them, or not trust them? In fact, taken far enough... why trust me? Much of the trust imparted in us is probably for two reasons: 1. the software is cheap 2. perception of our software management practices relative to other's software management practices John, if you are paranoid, don't trust anyone... You know, these are ports. You trust all the upstreams? You're right. I don't like the amount of trust involved in modern computing. It made me uneasy before any of the recent revelations occurred. Now it's even worse. It's not something I obsess about but I just don't like it. Is it a bit silly? Yeah, probably, especially since I'm probably the most boring target ever with regards to being surveilled or whatever. But, at least in the country I'm in, you can't walk out your door without breaking at least a few laws. So I come back around to yeah, I probably should take some precautions and think about these things at least some. You're right, I have to trust someone to use modern computer hardware and operating systems. My strategy is to trust as few people as possible. I trust you and the other OpenBSD developers because of your stated principles and track record. Yeah, the price is right too. I trust payware less than free/open source software because I have to completely trust the software provider with payware whereas free/open source has at least some review by others. I haven't been able to contribute monetarily yet except buying a LibreSSL shirt. I hope to be able to change that soon and start contributing on a regular basis. So while the price is right more from a perspective of free/open vs payware it isn't so much about the money (which I truly do want to start gladly giving whenever I am able to which should be soon). With regards to mtier specifically, I didn't see a mention of it anywhere on openbsd.org. So my initial reaction was thanks but no thanks. If it really is considered trustworthy by core OpenBSD developers then maybe I'll take another look. -- John Merriam
Re: .kshrc Definitions under X
On 4/10/2015 8:03 PM, Henrique Lengler wrote: On Fri, Apr 10, 2015 at 07:51:01PM -0400, dan mclaughlin wrote: you should see an '-ls' option at the end as above. if not, that is your problem (it's not invoking a login shell), and this should work: I know that xterm isn't being started with -ls option and it solve thw problem. But this couldn't be normal, is it? Because my intention is not to use only xterm but also others term. emulators like st, and I would like to have they working as it does in any other system. If this is normal, will I need to configure and make sure that every term. emulator I'm using is loading .profile. On Sun, Apr 05, 2015 at 09:22:03PM -0700, Philip Guenther wrote: B) tell xterm to start the shell inside it as a login shell, so that *that* will read your .profile. This can be done by either: B1) start xterm with the -ls option, or B2) set "*loginShell: true" in your X resource database (c.f. xrdb(1)) also, xterm may be invoked elsewhere like in your ~/.xinitrc, so you would need to fix it there, but the xrdb option should take care of that. See the -l option of ksh. Also search for the word login in the ksh man page. ksh (and most if not all other shells I believe) behave differently if they think they are a login shell. xterm does not not automatically tell the shell that is invoked when it starts that the shell should be a login shell. That is why the -ls xterm option exists. It can be useful not to tell the shell invoked by xterm that it is a login shell when you are running something in xterm besides an interactive command prompt session. See the xterm man page. You can run things in an xterm besides just a command prompt shell (shell scripts, other text programs, etc.) in which case you wouldn't want login shell type things being set up. -- John Merriam
Apache2 on 5.7 = certificate error
Hello. I have upgraded my home server from OpenBSD 5.6 to 5.7. It is amd64 and it is on -stable with -stable ports. Everything is working fine after the upgrade except SSL in Apache2 (apache-httpd package/port). I get the following error in the error_log when I try to start Apache2: [Mon May 18 09:51:43 2015] [error] Failed to configure CA certificate chain! The certificate is a wildcard certificate from RapidSSL. I have their 'intermediate CA bundle' from here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO26459 in a file that is pointed to with the SSLCertificateChainFile directive in my Apache2 config. This worked fine with the old Apache2 in 5.6. I've tried several different things to try to convince it to work but nothing has done the trick yet. I use the same certificate in sendmail and dovecot on the same server and it is working fine with those two daemons. Any ideas or suggestions as to what the problem may be or where I should start digging? Thanks! -- John Merriam
Re: Apache2 on 5.7 = certificate error
On Mon, 18 May 2015, Stefan Sperling wrote: > On Mon, May 18, 2015 at 10:04:03AM -0400, John Merriam wrote: > > I get the following error in the error_log when I try to start Apache2: > > > > [Mon May 18 09:51:43 2015] [error] Failed to configure CA certificate > > chain! > > > > The certificate is a wildcard certificate from RapidSSL. > > > > I have their 'intermediate CA bundle' from here: > > > > https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO26459 > > > > in a file that is pointed to with the SSLCertificateChainFile directive in > > my Apache2 config. > > What does this file contain exactly? I believe mod_ssl expects the server > certificate followed by any intermediate CA certificates up to the root > CA cert, all in PEM format, in one file. > > It's very odd that the behaviour between 5.6 and 5.7 changed. > None of the upstream changes between 2.2.27 and 2.2.29 seem to apply. > http://www.apache.org/dist/httpd/CHANGES_2.2 > > Given your error message, the point of failure in mod_ssl is a call to > SSL_CTX_use_certificate_chain(), a function name which exists in mod_ssl > and also existed in LibreSSL for a brief period before 5.7. > During which time mod_ssl's version was renamed in our ports tree. > Before release, LibreSSL's function was renamed and mod_ssl's version > renamed back to its original name. This should not matter at all unless > something unexpected happened during release package builds (unlikely). > > Can you make it work by using alternative configuration options, such as > SSLCertificateFile and SSLCACertificateFile or SSLCACertificatePath? > Yes, it was very odd to me as well that it didn't work after the upgrade. I didn't change a single bit of my Apache2 config. I checked /usr/local/share/examples/apache2/conf/* for changes after the upgrade. Since there were none I didn't change anything. I just changed SSLCertificateChainFile to SSLCACertificateFile in my httpd-ssl.conf and it works! I should have thought of trying something like that... The file pointed to in my SSLCertificateChainFile (and now SSLCACertificateFile) directives contains: -BEGIN CERTIFICATE- MIIEJTCCAw2gAwIBAgIDAjp3MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i YWwgQ0EwHhcNMTQwODI5MjEzOTMyWhcNMjIwNTIwMjEzOTMyWjBHMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEgMB4GA1UEAxMXUmFwaWRTU0wg U0hBMjU2IENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCv VJvZWF0eLFbG1eh/9H0WA//Qi1rkjqfdVC7UBMBdmJyNkA+8EGVf2prWRHzAn7Xp SowLBkMEu/SW4ib2YQGRZjEiwzQ0Xz8/kS9EX9zHFLYDn4ZLDqP/oIACg8PTH2lS 1p1kD8mD5xvEcKyU58Okaiy9uJ5p2L4KjxZjWmhxgHsw3hUEv8zTvz5IBVV6s9cQ DAP8m/0Ip4yM26eO8R5j3LMBL3+vV8M8SKeDaCGnL+enP/C1DPz1hNFTvA5yT2AM QriYrRmIV9cE7Ie/fodOoyH5U/02mEiN1vi7SPIpyGTRzFRIU4uvt2UevykzKdkp YEj4/5G8V1jlNS67abZZAgMBAAGjggEdMIIBGTAfBgNVHSMEGDAWgBTAephojYn7 qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUw5zz/NNGCDS7zkZ/oHxb8+IIy1kwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMEwGA1UdIARF MEMwQQYKYIZIAYb4RQEHNjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3Lmdlb3Ry dXN0LmNvbS9yZXNvdXJjZXMvY3BzMA0GCSqGSIb3DQEBCwUAA4IBAQCjWB7GQzKs rC+TeLfqrlRARy1+eI1Q9vhmrNZPc9ZE768LzFvB9E+aj0l+YK/CJ8cW8fuTgZCp fO9vfm5FlBaEvexJ8cQO9K8EWYOHDyw7l8NaEpt7BDV7o5UzCHuTcSJCs6nZb0+B kvwHtnm8hEqddwnxxYny8LScVKoSew26T++TGezvfU5ho452nFnPjJSxhJf3GrkH uLLGTxN5279PURt/aQ1RKsHWFf83UTRlUfQevjhq7A6rvz17OQV79PP7GqHQyH5O ZI3NjGFVkP46yl0lD/gdo0p0Vk8aVUBwdSWmMy66S6VdU5oNMOGNX2Esr8zvsJmh gP8L8mJMcCaY -END CERTIFICATE- -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwNTIxMDQwMDAwWhcNMTgwODIxMDQwMDAw WjBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UE AxMSR2VvVHJ1c3QgR2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2swYYzD99BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9m OSm9BXiLnTjoBbdqfnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIu T8rxh0PBFpVXLVDviS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6c JmTM386DGXHKTubU1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmR Cw7+OC7RHQWa9k0+bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5asz PeE4uwc2hGKceeoWMPRfwCvocWvk+QIDAQABo4HwMIHtMB8GA1UdIwQYMBaAFEjm aPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBTAephojYn7qwVkDBF9qn1luMrM TjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+g LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDBO BgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cuZ2Vv dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5M
Re: df(1) shows strange Avail and Capacity info
On Tue, 19 May 2015, Theo de Raadt wrote: > > I experienced a strange output of df(1) for the root partition. > > The Size is greater than Used but Avail and Capacity are miscalculated > > That is an incorrect assessment. > > There is spare space in the filesystem, only available for root, and > this is how it is handled. > Yes, df is functioning correctly. It looks like you have 5% of the space on your / partition reserved for the root user. You have less than 5% of the space on / available. When you have less than the reserved amount of space available on a partition df will show greater than 100% capacity used and a negative amount of space available. It's sort of a warning. If any process that is not owned by root tries to write something to your / partition, it will fail. You can see the percentage of reserved space on your / partition with: tunefs -N / You can also see a description of this feature in the notes for the -m option in the tunefs(8) man page. -- John Merriam
Re: Openbsd 5.7 and sendmail
On Tue, 26 May 2015, Peter Fraser wrote: > I put OpenBSD 5.7 up, but because we make use of the SpamHaus I didn't want > to move to smtpd. > > It was easy enough to put sendmail in but I found I could not rebuild my > /etc/mail/access.db > > makemap did not like the "To:" prefix in the /etc/mail/access file. > > being somewhat slow to took me a couple of days to realize that there are now > 2 makemap's > > /usr/libexec/smtpd/makemap > > and > > /usr/local/libexec/sendmail/makemap > > using the right one for sendmail fixed my problem. > You may need to edit your /etc/mailer.conf file. See the mailer.conf(5) man page and /usr/local/share/doc/pkg-readmes/sendmail-* -- John Merriam
Re: OpenBSD 5.7 & Asterisk & sendmail & voice mail as email
On Thu, 28 May 2015, Peter Fraser wrote: > Asterisk seems to run fine on 5.7 with one exception. > I normally have voice mail messages send as emails. > These emails are not being send. > > /usr/local/share/examples/asterisk/default/voicemail.conf > > has a variable > > ;mailcmd=/usr/sbin/sendmail -t > > which I believe will end up using smptd > > since I wanted to use sendmail > I put into my /etc/asterisk/voicemail.conf > > mailcmd=/usr/local/libexec/sendmail/sendmail -t > > and did a > > voicemail reload > from within asterisk and it still did not work. > > I even tried > mailcmd = sh -c cat >>/home/pjf/messages > > after creating message and chmod 777 messages > the file messages was not changed. > > any ideas on what I am missing > Have a look at /usr/local/share/doc/pkg-readmes/sendmail-* Particularly the 'Tweaking /etc/mailer.conf' and 'Client mail queue ownership' sections. I would bet that either your /var/spool/clientmqueue isn't owned by _smmsp:_smmsp or your submit.cf is using the old smmsp user/group. -- John Merriam
Staus of stacked softraid root (RAID1C for root)?
Hello. I was wondering if there was any new information about the status of stacked softraid for the root partition? I am particularly interested in using RAID1C for root partitions. I searched and the last message I could find regarding the subject was from over a year ago and I think the result was 'they are working on it'. From what I can find it doesn't look like it will be working for 5.6. I hope there will be a blurb about it in the release notes whenever it is included. Assuming it isn't right around the corner, is there anywhere that I can track the development of stacked softraid for the root partition? Any information you can provide would be greatly appreciated. -- John Merriam - refugee from the land of systemd
Re: Staus of stacked softraid root (RAID1C for root)?
On 10/20/2014 4:42 PM, Ted Unangst wrote: Short answer: It doesn't work yet, and no idea when it will work. Thanks for the replies. I will keep my eye out as to what is brewing. If I find the time maybe I'll read the code and see what needs doing with respect to RAID1C for root. For now I'll forgo the RAID1 and just use the crypto. I _really_ like the fact that OpenBSD encrypts as much as possible with softraid and doesn't leave a /boot hanging out there like other systems do with an encrypted root partition. It's been a while since I've used OpenBSD. Like what I'm seeing, keep up the great work! As you can see in my sig, I'm migrating away from one of those other operating systems... -- John Merriam - refugee from the land of systemd
Re: Staus of stacked softraid root (RAID1C for root)?
On Tue, 21 Oct 2014, Vladislav Manchev wrote: I asked a similar question on the list a few days ago and seems I'll be using a hardware RAID controller with softraid CRYPTO on top after all. It may be an option for you too I guess. Yeah, I probably should do hardware RAID for my server at home. At work it doesn't matter since there is no FDE and most if not all machines have hardware RAID controllers. In the past I've always liked doing software RAID for RAID1 since the OS can see the actual drives and start complaining if there is a problem with one of them. With hardware RAID you have to rely on the controller figuring it out and some utility to probe the controller. RAID5 and 6 are obviously always best on a hardware RAID controller for performance reasons. My main issue at home is my firewall which is a Mini-ITX machine with only one expansion slot which has a network card in it so hardware RAID won't be happening there. Now that I'm thinking about it though, I should probably skip the crypto for the firewall and just use non-sensitive passwords. My only real worry if the firewall is stolen is that they could possibly decrypt the passwords on it since there isn't any other possibly interesting infomation on it. Not like I have much interesting information on my server either but I still don't want to worry if my machines are stolen or something. Hmmm. Thanks again for helping me think through my options! -- John Merriam - refugee from the land of systemd
