Re: spamd in blacklist only modexd
On 12/10/13 08:28, Jason McIntyre wrote:
On Mon, Dec 09, 2013 at 10:35:36PM +0100, Maurice Janssen wrote:
On 12/09/13 08:41, Jason McIntyre wrote:
On Sun, Dec 08, 2013 at 07:59:48PM +0100, Maurice Janssen wrote:
Hi,
If I understand the man pages correctly, you should start both spamd and
spamd-setup with the -b option when you want to use spamd in blacklist only
mode.
In /etc/rc.d/spamd, the -b option is set when you have spamd_black=yes in
your rc.conf.local.
However, spamd-setup is always started with -D only from /etc/rc. It doesn't
check for the spamd_black environment variable and therefore set -b.
So it seems that you have to adapt /etc/rc when you want to run spamd in
blacklist only mode.
This seems a bit odd, doesn't it? Am I missing something, or is this
intended?
Thanks,
Maurice
you shouldn;t have to mess about with the rc.d stuff at all.
you run spamd with the -b flag on the command line, or set spamd_black
in rc.conf.local.
then, following through the man page:
spamd-setup(8) should be run periodically by cron(8). When
run in blacklist-only mode, the -b flag should be specified.
Use crontab(1) to uncomment the entry in root's crontab.
hope that's clear.
jmc
Thanks, the cron part is clear. When spamd-setup is run from cron (with -b),
spamd-setup downloads the blacklists as configured in spamd.conf and sends
the data to the pf table spamd and to the spamd process. So far so good.
But when spamd-setup is run during boot from /etc/rc (without -b), it
doesn't send the IPs from the blacklists to pf. Therefore, connections
from blacklisted IP's are not redirected to spamd and spamd is not
operational until spamd-setup is run from crontab (with -b). This can take
up to an hour with the default crontab entry. Not a big deal, but annoying.
So why not check for spamd_black in /etc/rc and run spamd-setup with -b in
case it is set?
Maurice
hi. i'm not the right person to answer that question. feel free to
mail a diff to tech and see if anyone replies.
you'll be aware, obviously, that you can tweak the crontab entry
to your liking if the suggested example doesn;t suit.
jmc
The OP is referring to this part of /etc/rc, which has nothing to do
with neither crontab nor /etc/rc.d/*.
if [ X${spamd_flags} != XNO ]; then
/usr/libexec/spamd-setup -D
fi
Indeed, please suggest a diff.
Maybe we should just incorporate that into /etc/rc.d/spamd instead?
/Alexander
Re: spamd in blacklist only modexd
On 2013-12-10 Tue 09:26 AM |, Alexander Hall wrote:
The OP is referring to this part of /etc/rc, which has nothing to do
with neither crontab nor /etc/rc.d/*.
if [ X${spamd_flags} != XNO ]; then
/usr/libexec/spamd-setup -D
fi
Indeed, please suggest a diff.
Maybe we should just incorporate that into /etc/rc.d/spamd instead?
This has worked OK for me for a few months:
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.407
diff -u -u -p -r1.407 rc
--- rc 9 Aug 2013 16:24:54 - 1.407
+++ rc 10 Dec 2013 12:59:49 -
@@ -499,10 +499,6 @@ start_daemon rbootd mopd popa3d spamd sp
start_daemon ipropd_master ipropd_slave sndiod
echo '.'
-if [ X${spamd_flags} != XNO ]; then
- /usr/libexec/spamd-setup -D
-fi
-
# If rc.firstime exists, run it just once, and make sure it is deleted
if [ -f /etc/rc.firsttime ]; then
mv /etc/rc.firsttime /etc/rc.firsttime.run
Index: rc.d/spamd
===
RCS file: /cvs/src/etc/rc.d/spamd,v
retrieving revision 1.3
diff -u -u -p -r1.3 spamd
--- rc.d/spamd 13 Sep 2013 14:50:56 - 1.3
+++ rc.d/spamd 10 Dec 2013 12:59:49 -
@@ -1,18 +1,23 @@
#!/bin/sh
#
-# $OpenBSD: spamd,v 1.3 2013/09/13 14:50:56 okan Exp $
+# $OpenBSD: spamd,v 1.4 2013/09/05 19:08:22 skinner Exp $
-daemon=/usr/libexec/spamd
+daemon='/usr/libexec/spamd'
. /etc/rc.d/rc.subr
pexp=spamd: \[priv\]
rc_reload=NO
-rc_pre() {
- [ X${spamd_black} != XNO ] \
- daemon_flags=-b ${daemon_flags}
- return 0
+rc_pre()
+{
+ [[ ${spamd_black} == 'NO' ]] || daemon_flags=-b ${daemon_flags}
+}
+
+rc_start()
+{
+ ${rcexec} ${daemon} ${daemon_flags} ${_bg}
+ rc_do rc_wait start ${daemon}-setup -D
}
rc_cmd $1
Cheers,
--
Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Asterisk console dial
Hello, can I somehow enable console dial from asterisk CLI (e.g. console dial 100@default) to test if some extension in dialplan is working? In /usr/local/lib/asterisk/modules I can't find chan_oss.so or chan_console.so so I think it is out on purpose because this works in Linux distributions. Loading these channels in /etc/asterisk/modules.conf doesn’t help. Thank you. /davor
Re: alix2d3 entry point at 0x200120 after PXE installation
Hi all,
Unfortunately, I still get the reboot after the installation on my alix2d3.
I already installed a Debian image into the flash with success so the flash
seems fine.
I need a custom disklabel so maybe it's where it failed.
Let me do a resume of my configuration and all I did.
Thanks for your support,
Cheers,
Aurelien
Logs
--
The BIOS (0.99h) settings
--
*9* 9600 baud
*C* CHS mode
*R* Serial console enable
*E* PXE boot enable
In pxe boot.conf file:
-
stty com0 9600
set tty com0
boot tftp:/bsd54.rd
The OpenBSD 5.4 installation
---
...
Change the default console to com0? [no] yes
Which one should com0 use? (or 'done') [9600]
Available disks are: wd0.
Which disk is the root disk? ('?' for details) [wd0]
Use DUIDs rather than device names in fstab? [yes] no
MBR has invalid signature; not showing it.
Use (W)hole disk or (E)dit the MBR? [whole] W
Setting OpenBSD MBR partition to whole wd0...done.
Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a] C
- I need a custom disk label -
OpenBSD area: 64-15647310; size: 15647246; free: 14
#size offset fstype [fsize bsize cpg]
a: 626464 64 4.2BSD 2048 163841 # /
b: 512 626528swap
c: 156623040 unused
d: 272576 627040 4.2BSD 2048 163841 # /home
e: 257056 899616 4.2BSD 2048 163841 # /tmp
f: 12578880 1156672 4.2BSD 2048 163841 # /usr
g: 1911744 13735552 4.2BSD 2048 163841 # /var
w
q
No label changes.
newfs: reduced number of fragments per cylinder group from 39152 to 38992
to enlarge last cylinder group
/dev/rwd0a: 305.9MB in 626464 sectors of 512 bytes
5 cylinder groups of 76.16MB, 4874 blocks, 9856 inodes each
newfs: reduced number of fragments per cylinder group from 17032 to 16960
to enlarge last cylinder group
/dev/rwd0d: 133.1MB in 272576 sectors of 512 bytes
5 cylinder groups of 33.12MB, 2120 blocks, 4352 inodes each
newfs: reduced number of fragments per cylinder group from 16064 to 15992
to enlarge last cylinder group
/dev/rwd0e: 125.5MB in 257056 sectors of 512 bytes
5 cylinder groups of 31.23MB, 1999 blocks, 4096 inodes each
/dev/rwd0f: 6142.0MB in 12578880 sectors of 512 bytes
31 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each
/dev/rwd0g: 933.5MB in 1911744 sectors of 512 bytes
5 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each
/dev/wd0a on /mnt type ffs (rw, asynchronous, local)
/dev/wd0d on /mnt/home type ffs (rw, asynchronous, local, nodev, nosuid)
/dev/wd0e on /mnt/tmp type ffs (rw, asynchronous, local, nodev, nosuid)
/dev/wd0f on /mnt/usr type ffs (rw, asynchronous, local, nodev)
/dev/wd0g on /mnt/var type ffs (rw, asynchronous, local, nodev, nosuid)
# fdisk wd0
Disk: wd0 geometry: 974/255/63 [15662304 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start:size ]
---
0: 00 0 0 0 - 0 0 0 [ 0: 0 ]
unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ]
unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ]
unused
*3: A6 0 1 2 -973 254 63 [ 64:15647246 ]
OpenBSD
After the reboot
-
boot
booting hd0a:/bsd: 8824220+1096236=0x97613c
entry point at 0x200120
[then reboot in loop]
- I also try with wd0a
boot boot wd0a:/bsd
booting wd0a:/bsd: 8824220+1096236=0x97613c
entry point at 0x200120
[then reboot in loop]
2013/12/3 Aurelien Martin 01aurel...@gmail.com
Hi all,
I would like to thanks all to your fast feedback and support
I'm moving my flat so I cannot test for these days. On Thursday I'll
receive a new USB - DB9 Null modem cable and a flash card reader.
So the next days I'll update this feed with my observation, tests and
steps to achieve it through PXE. As mentioned if it doesn't work I'll put
directly OBSD 5.4 on the flash.
Have a good day
Aurelien
2013/11/30 Eike Lantzsch zp6...@gmx.net
On Friday 29 November 2013 17:12:45 Erling Westenvik wrote:
On Fri, Nov 29, 2013 at 01:10:24PM +0100, Aurelien Martin wrote:
stty com0 57600
I too would try with a lower baudrate.
From the FAQ (http://www.openbsd.org/faq/faq7.html#SerCon)
Resist the urge to crank the baud rate up to the maximum your
hardware can support, as you are more likely to create problems
than benefit. Most systems have a default speed (supported by
default by the boot ROM and/or the boot loader, often 9600), use
this unless you have real reason to use something different.
Huh? My ALIX 2D13 works fine with 115200 - no quirks.
38400
Re: BackupPC
I have not had any troubles with BackupPC (on the Debian system). BackupPC does deduplication which I don't believe that Bacula does. From the point of view of the clients the backups are done automatically, as long as they leave their computers on and connected to the network. The web service of BackupPC is how files can be restored, which I cannot get to run. I may have to rebuild a Debian system. BackupPC backing up of Windows system is not complete. It will not backup busy files. So a manual process for backing up database files has to be used. I keep backups monthly for two years, weekly for 6 months and daily for 2 months. BackupPC also has trouble with Windows junction points. I have those removed in the configuration files. I have found any not troubles with backing up Unix like systems. If you ask google open source backup deduplication BackupPC is the only one on the list. Deduplication drastically shrinks the size of the file store. The previous backup system that was in use could only store 2 or 3 backup on 2 Terabytes. The older backups were put on tape. Now (or at least a week ago) I have two years of backups on 4 Terabytes, and I have no tapes. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Peter N. M. Hansteen Sent: Monday, December 09, 2013 3:49 PM To: 'misc@openbsd.org' Subject: Re: BackupPC Peter Fraser p...@thinkage.ca writes: For years I have a had Debian system that ran BackupPC. The system was used to back up a bunch of Windows workstations and servers. The Debian system self-destructed when doing a update. I must admit this is the first I heard of BackupPC, but since this sounds like at time when some grunt work is to be expected anyway, I thought it may not be totally useless to recommend looking at a different backup product. The only backup system I've actually ever enjoyed working with is Bacula (in packages, and it supports a wide range of systems, including the Seattle-area ones). More complicated than tar or rsync for sure, but it scales and is in my experience at least a very admin-friendly solution. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: (5.3) load problem on em(4) MSI / interrupt ?
On 2013-12-09, Patrick Lamaiziere patf...@davenulle.org wrote: Le Mon, 09 Dec 2013 12:31:04 +, Stuart Henderson s...@spacehopper.org a écrit : Hello, I don't think msi can be re-enabled for this part in OpenBSD, the reason it's disabled is that there is a bug in the 82571/2 chips (errata 63 in http://www.intel.co.uk/content/dam/www/public/us/en/documents/specification-updates/82571eb-82572ei-gbe-controller-spec-update.pdf) and the symptom in affected machines is that the card doesn't transmit at all, so unless someone else has a clever idea I think this will need to remain a local patch. I agree, I've read the bug report (http://openbsd.7691.n7.nabble.com/Intel-PRO-1000-PF-em-network-card-not-working-with-MSI-on-Dell-R610-td195975.html) and we use a later bios on our R610, may be it fix this issue : bios0: vendor Dell Inc. version 2.1.15 date 09/02/2010 bios0: Dell Inc. PowerEdge R610 Thing is, it's not an R610 problem, the R610 is following the specs and running into bugs in the nic, and other machines might well also follow the spec and also fail with this nic. (the number of erratas for this card is incredible!) It might look bad but this isn't particularly unusual! Many of these can be worked-around in the driver. Fortunately in this case the vendor does publish this sort of information rather than just silently working around in their own driver, you can imagine what it's like for people trying to reverse-engineer undocumented hardware.. Note that many of these errata (e.g. those mentioning BMC, SOL, RMCP, RAKP 1 and most if not all SMBus) are mostly concerned with sharing a nic doing IPMI management with the OS, so aren't really relevant to OpenBSD.
Re: NAT64 troubleshooting
On 2013-12-10, dikshie diks...@gmail.com wrote:
Hi,
I just built an openbsd box for NAT64 gateway
I can't figure out how the af-to works.
There were problems with af-to in some recent versions, but since you
didn't include the dmesg, I can't say if this applies to you..
http://www.openbsd.org/report.html
3. The OpenBSD kernel output. You can get this with the dmesg command,
but it is possible that your dmesg output does not contain all the
information that is captured in /var/run/dmesg.boot. If this is the
case, include information from both. PLEASE INCLUDE THIS IN ALL BUG
REPORTS.
BTW you're probably better off using BIND 9 from ports which has
built-in DNS64 support, rather than totd. BIND config is something
like this (in the options section) :-
dns64 2xxx:xxx::6464::/96 { clients { any; }; };
Re: BackupPC
BackupPC has an account _backuppc on OpenBSD (backuppc on Debian) which has to have permissions on the system that it is backing up. LDAP is the one responsible for granting the permissions. Configuration within BackupPC (a pain) is specifies what a user can see in the backups and what a user can restore. The busy file problem occurs when using a Windows system not a Unix system. Using a Windows system there is no way to look at an open file unless shadow copies are used and you are not going to use that more than once a day. I tried to create a shadow copy before a backup but I found created shadow copies unreliable with too many random errors. I probably should try again to use shadow copies before a backup, hoping that Microsoft has fixed the problems, but I haven't done it. My backups are taken early in the morning and rarely is any one a computer. Also the shadow copy has special deals with things like Exchange and the MS-SQL giving the net effect you can't use shadow to get a copy of the database anyway. As far a dump and rsync.,I didn't say there were no other ones. I gave a reasonable google search. You can try it. I would have expected you to say rsnapshot which is a good package. I use it to back up my DMZ machines (all OpenBSD). Backing up Windows machines is my problem; I want it automated and fool proof as possible. -Original Message- From: Jan Stary [mailto:h...@stare.cz] Sent: Tuesday, December 10, 2013 12:13 PM To: Peter Fraser Subject: Re: BackupPC On Dec 10 15:53:52, p...@thinkage.ca wrote: I have not had any troubles with BackupPC (on the Debian system). BackupPC does deduplication which I don't believe that Bacula does. From the point of view of the clients the backups are done automatically, as long as they leave their computers on and connected to the network. ... and let someone from somewhere read their disk. Isn't that a _major_ security consideration? BackupPC backing up of Windows system is not complete. It will not backup busy files. So a manual process for backing up database files has to be used. Also, the most important document I am working on just now, will _not_ be backed up, right? So after my workstation burns one minute later, the work is just lost, right? If you ask google open source backup deduplication BackupPC is the only one on the list. Bullshit; dump and rsync can do hardlinks and symlinks.
Re: BackupPC
On 2013-12-09, Dennis Davis dennisdavis+openbsd-m...@fastmail.fm wrote: You might find the OpenBSD port/package of openpam: /usr/ports/security/openpam of use in getting authentication via winbindd working. I've never used openpam myself, just installed it to satisfy the build requirement of other software. This is not going to help, what you are looking for is nsswitch, but OpenBSD does not support that. On 2013-12-09, Peter Fraser p...@thinkage.ca wrote: In my case, my user community is slowly changing, it is not too much work to manual created a OpenBSD account for each BackupPC user. You *might* possibly get somewhere by grabbing a snapshot of the account database from Windows via ldapsearch, and creating system users based on that. You might even get somewhere with ypldap though probably not particularly straightforward.. I think you're looking along the right lines with login_ldap to handle password auth.
Re: spamd in blacklist only modexd
On 12/10/13 14:03, Craig R. Skinner wrote:
On 2013-12-10 Tue 09:26 AM |, Alexander Hall wrote:
The OP is referring to this part of /etc/rc, which has nothing to do
with neither crontab nor /etc/rc.d/*.
if [ X${spamd_flags} != XNO ]; then
/usr/libexec/spamd-setup -D
fi
Indeed, please suggest a diff.
Maybe we should just incorporate that into /etc/rc.d/spamd instead?
This has worked OK for me for a few months:
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.407
diff -u -u -p -r1.407 rc
--- rc 9 Aug 2013 16:24:54 - 1.407
+++ rc 10 Dec 2013 12:59:49 -
@@ -499,10 +499,6 @@ start_daemon rbootd mopd popa3d spamd sp
start_daemon ipropd_master ipropd_slave sndiod
echo '.'
-if [ X${spamd_flags} != XNO ]; then
- /usr/libexec/spamd-setup -D
-fi
-
# If rc.firstime exists, run it just once, and make sure it is deleted
if [ -f /etc/rc.firsttime ]; then
mv /etc/rc.firsttime /etc/rc.firsttime.run
Index: rc.d/spamd
===
RCS file: /cvs/src/etc/rc.d/spamd,v
retrieving revision 1.3
diff -u -u -p -r1.3 spamd
--- rc.d/spamd 13 Sep 2013 14:50:56 - 1.3
+++ rc.d/spamd 10 Dec 2013 12:59:49 -
@@ -1,18 +1,23 @@
#!/bin/sh
#
-# $OpenBSD: spamd,v 1.3 2013/09/13 14:50:56 okan Exp $
+# $OpenBSD: spamd,v 1.4 2013/09/05 19:08:22 skinner Exp $
-daemon=/usr/libexec/spamd
+daemon='/usr/libexec/spamd'
. /etc/rc.d/rc.subr
pexp=spamd: \[priv\]
rc_reload=NO
-rc_pre() {
- [ X${spamd_black} != XNO ] \
- daemon_flags=-b ${daemon_flags}
- return 0
+rc_pre()
+{
+ [[ ${spamd_black} == 'NO' ]] || daemon_flags=-b ${daemon_flags}
+}
+
+rc_start()
+{
+ ${rcexec} ${daemon} ${daemon_flags} ${_bg}
+ rc_do rc_wait start ${daemon}-setup -D
}
rc_cmd $1
Cheers,
Nice, but this also fails to add -b to spamd-setup. How about this (and
of course remove the spamd-setup bits from /etc/rc):
--- spamd.orig Tue Dec 10 21:24:48 2013
+++ spamd Tue Dec 10 21:24:14 2013
@@ -15,4 +15,12 @@
return 0
}
+rc_start() {
+ ${rcexec} ${daemon} ${daemon_flags} ${_bg}
+ spamd_setup_flags=-D
+ [ X${spamd_black} != XNO ] \
+ spamd_setup_flags=-b ${spamd_setup_flags}
+ rc_do rc_wait start /usr/libexec/spamd-setup ${spamd_setup_flags}
+}
+
rc_cmd $1
Re: Are there any default password managers in OpenBSD?
On Thu, 5 Dec 2013, obsd, cgi wrote: So I know the rule.. only remember a few very very long passwords (ex.: based on several words and a few special chars), and keep the rest of the passwords in a password manager (those aren't remembered and extreme long). I'm not at all convinced that adding any special characters will accomplish much to a good password. When you are just using short passwords, they may be of help by expanding the number of characters used in the password. If you choose your password chacters from lower case letters, upper case letters, numbers, and a selection of 8 punctuation marks, then you would have a grand total of 70 characters. If the password is 8 characters long, then that would be 70^8 different passwords that could be generated. That is, 5.7648 * 10^14 possible passwords. Suppose that you instead choose five words at random from a dictionary of 10,000 entries. Then that would be 1^5 or 10^20 possible passwords without having to resort to tricks that make it harder to remember the password. My best passwords are nonsense sentences about 80 to 100 characters long. For example: There are no goldfish in the story of the three little wolves and the big bad piglet. Eric
Re: dhcpd: rejecting bogus offer
On Mon, Dec 9, 2013 at 3:01 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: Malicious or confused. Or truncated packets. The log message means that the option length as given in the packet would run the option data outside the received packet. The confusion might have started in an earlier option, unless you are actually providing Novell Service Location Protocol info? Nothing like that. Pretty ordinary setup. Got a really strange one today: Dec 10 16:19:46 firewall dhcpd[29710]: option nds-context (97) larger than buffer. Dec 10 16:19:46 firewall dhcpd[29710]: Many bogus options seen in offers. Dec 10 16:19:46 firewall dhcpd[29710]: Taking this offer in spite of bogus Dec 10 16:19:46 firewall dhcpd[29710]: options - hope for the best! ??
Re: NAT64 troubleshooting
On Wed, Dec 11, 2013 at 2:33 AM, Stuart Henderson s...@spacehopper.org wrote:
There were problems with af-to in some recent versions, but since you
didn't include the dmesg, I can't say if this applies to you..
http://www.openbsd.org/report.html
i use openbsd 5.4
---
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 15:24:05 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 520081408 (495MB)
avail mem = 498601984 (475MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x1ef0 (10 entries)
bios0: vendor Bochs version Bochs date 01/01/2007
bios0: Bochs Bochs
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: QEMU Virtual CPU version 0.14.1, 2328.07 MHz
cpu0:
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 1000MHz
mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type ISA
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: QEMU HARDDISK
wd0: 16-sector PIO, LBA48, 30720MB, 62914560 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 0.14 ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: apic 1 int 11
piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: apic 1 int 9
iic0 at piixpm0
-
BTW you're probably better off using BIND 9 from ports which has
built-in DNS64 support, rather than totd. BIND config is something
like this (in the options section) :-
dns64 2xxx:xxx::6464::/96 { clients { any; }; };
i'll consider dns64 under bind in the future.
--
-dikshie-
Re: dhcpd: rejecting bogus offer
On Tue, Dec 10, 2013 at 8:04 PM, Chris Smith obsd_m...@chrissmith.org wrote: Dec 10 16:19:46 firewall dhcpd[29710]: Many bogus options seen in offers. In particular the above line: Many bogus options seen in offers. Doesn't the server make the offer? If so, why would the OpenBSD dhcpd server create bogus options? Or am I misreading the intent of the log message?
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
On 12/09/2013 08:51 PM, Steve Shockley wrote: On 12/9/2013 7:24 PM, Adam Jensen wrote: Disk performance is *very* bad. For example: Shot in the dark, but maybe try upgrading the 6404 firmware from 2.34 to 2.84, there are a variety of fixes that possibly could have been worked around by the other OS' drivers. Nice call, Steve! I upgraded the Smart Array 6404 firmware to version 2.84 and all seems well now. I do see a curious difference in performance when writing to the /home partition verses writing to the /tmp partition: OpenBSD5.4-amd64 FW-v2.84 Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0o 59.0G 30.0K 56.1G 0%/home dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 4.929 secs (108916550 bytes/sec) Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0e 7.9G297M7.2G 4%/tmp dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 4.098 secs (130989620 bytes/sec) It might be interesting to explore this and maybe think about file system tuning. The FreeBSD performance is somehow still a little better. FreeBSD9.2-amd64 FW-v2.84 dd if=/dev/zero of=test bs=1k count=524288 536870912 bytes transferred in 3.733867 secs (143784149 bytes/sec) This is with the default partitioning scheme (boot and swap partitions, and everything else in one big partition). Another important point that I forgot to mention in the original post of this thread is that the write cache is currently disable on the RAID controller card. The machine gives this POST Message during startup: 1794 - Slot 2 Drive Array - Array Accelerator Battery Charge Low Array Accelerator Posted-Write Cache is temporarily disabled. Array Accelerator batteries have failed to charge and should be replaced. I've mail-ordered two replacement battery packs; they should be here next week. It will be interesting to see how an enabled 192MB write cache will affect performance.
Re: dhcpd: rejecting bogus offer
On Tue, Dec 10, 2013 at 22:16, Chris Smith wrote: On Tue, Dec 10, 2013 at 8:04 PM, Chris Smith obsd_m...@chrissmith.org wrote: Dec 10 16:19:46 firewall dhcpd[29710]: Many bogus options seen in offers. In particular the above line: Many bogus options seen in offers. Doesn't the server make the offer? If so, why would the OpenBSD dhcpd server create bogus options? Or am I misreading the intent of the log message? The option parsing code was at one time shared between dhclient and dhcpd. (ironically, our dhclient no longer contains that message.) It's worded strangely for a server warning message, but client requests are allowed to specify options to the server. Just replace the word offers with requests and it all makes sense.
Re: 5.4 amd64 - Poor disk performance with Smart Array 6404
This might not be terribly relevant but just in case, for posterity, the ML370 G4 system messages (dmesg) with both versions of the Smart Array 6404 firmware are here: OpenBSD5.4-amd64 [v2.34]: http://pastebin.com/Sxs801ef [v2.84]: http://pastebin.com/RGUJ5pcS FreeBSD9.2-amd64 [v2.34]: http://pastebin.com/xxphWLr2 [v2.84]: http://pastebin.com/zcxRPz4Y diff v2.34 v2.84 OpenBSD5.4-amd64 sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 2.34 SCSI0 0/direct fixed --- sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 2.84 SCSI2 0/direct fixed FreeBSD9.2-amd64 da0: COMPAQ RAID 0 OK Fixed Direct Access SCSI-0 device --- da0: COMPAQ RAID 0 OK Fixed Direct Access SCSI-4 device
