Re: OpenBSD's 10th birthday -- how about a present?
Mike Hernandez wrote: On 10/21/05, Ramiro Aceves [EMAIL PROTECTED] wrote: Hi OpenBSD fans! My 3.8 CD preorder is sent also! I am waiting nervous for the 3.8 release! Nervous? You must mean anxious :) One of the main reasons I love OpenBSD is because there is so much less to be nervous about! Mike Well Mike, sorry, my english is not good, english is not my native language. ;-) Enjoy! Ramiro.
Re: Problem instaling OpenBSD on IBM xSeries 336
Hello all, Thank you for hint, amd64 architecture does work on our HW ! Everything was instaled fine (I instaled latest snapshot). But we have another problem. When I look into BIOS, there is no possibility to do good irq routing. BIOS groups almost all devices to irq3 :( I can change irq, but I cannot change number of devices on this interrupt. There is IRQ for both internal ethernet broadcom cards, IRQ for PCIx slot, HDD, ... and more. I think this is very bad. I do not know if it is due to this simple irq but we have this problems: - disk operations are VERY slow (does not matter, no problem for us, it is firewall). - entire traffic is going thru cpu0. Cpu1 is unused. I think that if two cards are on another irq, it could be possible - througnput of entire system with large packets is somewhere at 120mbps. After it, CPU0 spend all time in interrupts. - I think this machine should be firewalling at much more speed. Please can you help me ? Is there any chance how to change irq if BIOS routes it bad? Or is there another way how to use both CPUs for firewalling? Thank you very much ! Here is dmesg: OpenBSD 3.8-current (GENERIC.MP) #556: Sat Oct 15 14:22:53 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1073319936 (1048164K) avail mem = 908791808 (887492K) using 22937 buffers containing 107540480 bytes (105020K) of memory mainbus0 (root) mainbus0: Intel MP Specification (Version 1.4) (IBM ENSW X336 SMP) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.57 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,NXE,LONG cpu0: 2MB 64b/line 8-way L2 cache cpu0: apic clock running at 27107Hz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.12 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,NXE,LONG cpu1: 2MB 64b/line 8-way L2 cache mpbios: bus 0 is type PCI mpbios: bus 1 is type PCI mpbios: bus 2 is type PCI mpbios: bus 3 is type PCI mpbios: bus 4 is type PCI mpbios: bus 5 is type PCI mpbios: bus 6 is type PCI mpbios: bus 7 is type PCI mpbios: bus 8 is type ISA ioapic0 at mainbus0 apid 14: pa 0x81ba7f24, version 20, 24 pins ioapic1 at mainbus0 apid 13: pa 0x81ba7e24, version 20, 24 pins ioapic2 at mainbus0 apid 12: pa 0x81ba7d24, version 20, 24 pins mpbios: can't find ioapic 0 mpbios: can't find ioapic 0 pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel E7710 SMCH rev 0x0c Intel E7710 MCH ERR rev 0x0c at pci0 dev 0 function 1 not configured ppb0 at pci0 dev 2 function 0 Intel E7710 MCH PCIE rev 0x0c pci1 at ppb0 bus 2 ppb1 at pci0 dev 4 function 0 Intel E7710 MCH PCIE rev 0x0c pci2 at ppb1 bus 3 ppb2 at pci2 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci3 at ppb2 bus 4 mpt0 at pci3 dev 1 function 0 Symbios Logic 53c1030 rev 0x08: apic 13 int 4 (irq 10) mpt0: sending FW Upload request to IOC (size: 36, img size: 69956) mpt0: IM support: 4 scsibus0 at mpt0: 16 targets sd0 at scsibus0 targ 0 lun 0: LSILOGIC, 1030 IM IM, 1000 SCSI2 0/direct fixed sd0: 139898MB, 139898 cyl, 16 head, 128 sec, 512 bytes/sec, 286511104 sec total mpt0: target 0 Asynchronous at 0MHz width 8bit offset 0 QAS 0 DT 0 IU 0 ppb3 at pci2 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci4 at ppb3 bus 5 em0 at pci4 dev 1 function 0 Intel PRO/1000MT (82545GM) rev 0x04: apic 12 int 0 (irq 10), address 00:0e:0c:9c:07:13 ppb4 at pci0 dev 6 function 0 Intel E7710 MCH PCIE rev 0x0c pci5 at ppb4 bus 6 bge0 at pci5 dev 0 function 0 Broadcom BCM5721 rev 0x11, BCM5750 B1 (0x4101): apic 14 int 16 (irq 10) address 00:14:5e:0b:3e:ea brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb5 at pci0 dev 7 function 0 Intel E7710 MCH PCIE rev 0x0c pci6 at ppb5 bus 7 bge1 at pci6 dev 0 function 0 Broadcom BCM5721 rev 0x11, BCM5750 B1 (0x4101): apic 14 int 16 (irq 10) address 00:14:5e:0b:3e:eb brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 vendor Intel, unknown product 0x359b (class system subclass miscellaneous, rev 0x0c) at pci0 dev 8 function 0 not configured uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: apic 14 int 16 (irq 10) usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: apic 14 int 19 (irq 7) usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB rev 0x02: apic 14 int 23 (irq 5) usb2 at ehci0: USB revision 2.0 uhub2 at usb2 uhub2: Intel EHCI root hub, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered ppb6 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xc2 pci7 at ppb6
Re: DISKLESS tutorial that need feedback
On 10/23/05, Matthew Weigel [EMAIL PROTECTED] wrote: Well, except that hard links are filesystem specific, you can't cross filesystem boundaries with one. Also, depending on design, you probably actually want a single RO filesystem to serve as / for all diskless clients, and have smaller per-client RW volumes (like /etc) or per-user RW volumes (so each machine is identical and everyone can use each machine). uhm, so it would be possible sharing all dirs except /etc? what happens to /dev when a few clients want to access the same device? Each machine is identical? yes maybe in that case that would work. But where I'm going to use my doc is a uni env where all the clients are not identical. Even if they were, what would you do if hw failed on one of clients? And about keeping them synced, master.passwd is the most important thing for keeping the 'accounts' intact. So a script that sync one of the clients from server, and then all the other clients can sync from that up2date client. I would say next to master.passwd the important thing that should be synced is /usr which already in my case is mounted. Remeber that if the purpose is 'personal' thin clients you would confuse ppl saving tons of files in everyones /home. /bkw
Re: pxeboot halting...
How to use boot pxeboot is described in the doc I wrote two days ago,
you can find a link to it in the list. You'll find examples that I
hope will help.
gl
/bkw
On 10/23/05, poncenby smythe [EMAIL PROTECTED] wrote:
Hello list, help for the following problem would be greatly
appreciated, it's so frustrating.
Trying to pxeboot 3.7 on an EPIA machine with what Linux is reporting
to be a Centaur VIA Samuel 2 stepping 03 processor. The server is a
mac with os 10.4, here is the /etc/dhcpd.conf:
allow booting;
allow bootp;
ddns-update-style none;
shared-network LOCAL-NET {
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.88;
option root-path /tftpboot;
filename pxeboot;
range 192.168.1.32 192.168.1.52;
default-lease-time 86400;
max-lease-time 9;
}
}
The directory /tftpboot has the files pxeboot and bsd.rd and tftpd
has been verified to transfer files correctly. The EPIA machine is
pushed the pxeboot file and the usual prompt appears, so I type
bsd.rd and the spinning pipe character stays vertical and doesn'r move.
after a wait of around 1 minute the number 4302596 appears, about a
30 second wait then the following text appears:
read text: Unknown error: code 60
failed(60). will try /bsd.old
Perhaps I should copy the file bsd.old into the tftpboot directory
but I cannot find such a file.
Can anyone help me, I have attempted googling but not found much,
Any solution and I promise to submit my dmesg! - what an incentive :(
thanks in advance
poncenby
--
##
BKW - Bachman Kharazmi
bahkha AT gmail DOT com
uin: #24089491
SWEDEN
##
Re: DISKLESS tutorial that need feedback
On 10/23/05, Bachman Kharazmi [EMAIL PROTECTED] wrote: And about keeping them synced, master.passwd is the most important thing for keeping the 'accounts' intact. You may want to look into the yp(8) subsystem. For the enviroment you describe, this may be what you're looking for to keep many clients in sync when it comes to their password, group and host files. Cheers, Rogier -- If you don't know where you're going, any road will get you there.
external interface of a bridge not filtering for itself
Last spring I installed BSD onto a computer. Okay, so far. Now I have
installed BSD onto five computers. One of them is a OpenBSD 3.8 bridge on an
old i386.
The Packet Firewall rules all seemed logical, until I made the firewall; i.e,
bridge. Even though filtering is set to take place on the external
interface, ports 13, 22, 37, and 113 appear in a portscan. Why is this
happening?
My ruleset is basic, about like:
set skip on { lo $int_if }
scrub in
block all
antispoof quick for { lo $int_if }
pass in log quick on $eth_if proto { tcp, udp } from \
dns to this keep state
pass in log quick on $eth_if inet proto udp from \
ntp to this port 123 keep state
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state
I am considering a change to rc.conf.local:
sshd_flags=NO
inetd=NO
Can I disable inetd?
sshd would be convenient to run, to be connection-abled from the local
network, but not if the port is viewable from outside.
Is this typical of bridges? Cracked computer? Bad rules?
Darrel
Re: pxeboot halting...
thanks for the replies, the solution I found was to insert the
following line into /etc/dhcpd.conf
next-server dhcpd server ip address
if this line isn't in then the obsd machine displayed 0.0.0.0 as the
server ip.
thanks for the replies
poncenby
On 23 Oct 2005, at 11:04, Bachman Kharazmi wrote:
How to use boot pxeboot is described in the doc I wrote two days ago,
you can find a link to it in the list. You'll find examples that I
hope will help.
gl
/bkw
On 10/23/05, poncenby smythe [EMAIL PROTECTED] wrote:
Hello list, help for the following problem would be greatly
appreciated, it's so frustrating.
Trying to pxeboot 3.7 on an EPIA machine with what Linux is reporting
to be a Centaur VIA Samuel 2 stepping 03 processor. The server is a
mac with os 10.4, here is the /etc/dhcpd.conf:
allow booting;
allow bootp;
ddns-update-style none;
shared-network LOCAL-NET {
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.88;
option root-path /tftpboot;
filename pxeboot;
range 192.168.1.32 192.168.1.52;
default-lease-time 86400;
max-lease-time 9;
}
}
The directory /tftpboot has the files pxeboot and bsd.rd and tftpd
has been verified to transfer files correctly. The EPIA machine is
pushed the pxeboot file and the usual prompt appears, so I type
bsd.rd and the spinning pipe character stays vertical and doesn'r
move.
after a wait of around 1 minute the number 4302596 appears, about a
30 second wait then the following text appears:
read text: Unknown error: code 60
failed(60). will try /bsd.old
Perhaps I should copy the file bsd.old into the tftpboot directory
but I cannot find such a file.
Can anyone help me, I have attempted googling but not found much,
Any solution and I promise to submit my dmesg! - what an incentive :(
thanks in advance
poncenby
--
##
BKW - Bachman Kharazmi
bahkha AT gmail DOT com
uin: #24089491
SWEDEN
##
--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net
Re: Problem instaling OpenBSD on IBM xSeries 336
--On 23 October 2005 11:29 +0200, LukC!E! Macura wrote: When I look into BIOS, there is no possibility to do good irq routing. BIOS groups almost all devices to irq3 :( try a .mp kernel (even if you have 1 processor).
Re: external interface of a bridge not filtering for itself
--On 23 October 2005 08:30 -0400, Darrel wrote:
My ruleset is basic, about like:
about like isn't nearly as good as directly including the whole file.
to be complete you might also include 'ifconfig', 'brconfig -a' and
'netstat -rn -finet' to give us a better idea of the network (if you
absolutely must mask the IP addresses, consistently replace one of the
numbers, but be certain you don't cover up an typo by doing so). this
is far better than a written description or ascii-art since people that
might be able to help can read this type of output more easily.
pass in log quick on $eth_if proto { tcp, udp } from \
...
pass out on $ext_if proto tcp all modulate state flags S/SA
generally with a filtering bridge, you would want to pass all traffic
on one of the interfaces ('set skip on XX' or a 'pass on XX' rule), and
just make rules apply to the other interface. Whether or not this is
what you're doing, isn't clear from your message.
Is this typical of bridges?
No.
Re: DISKLESS tutorial that need feedback
** Reply to message from Bachman Kharazmi [EMAIL PROTECTED] on Sat, 22 Oct 2005 23:44:13 +0200 Please STOP the discussion about document formats in this thread. You're taking my time complaing on the document format (pdf). I do _not_ want to discourage anyone from creating new, useful documents, but why should decreased accessibility due to choosing a format that's not appropriate for general use on the web be treated differently from any other defect? If you're writing this purely for your own amusement, use any format you like -- but if you want _other_ people to read it on the web, you'll get better results if you provide it in pure standards-conforming HTML+CSS (since that's the form which is most likely to be convenient -- and least likely to cause problems -- for anyone trying to read it). In my first post I wrote that I want feedback on the document and nothing else. You _are_ getting feedback on the document: it's harder to read than it could be. Dave -- Dave Anderson [EMAIL PROTECTED]
Re: Interrupts on quad nics
Digging through the backlog, and found this unanswered... Joe S wrote: Since some quad nics share 1 interrupt, what kind of performance impact would I be dealing with versus using 4 indiviual nics? Debating wehter to use a Phobox P430TX quad dc nic or individual fxp0 nics. Just test it and find out. On the criteria you specify, shared vs. individual IRQs, you are unlikely to see any difference. (it was believed that shared IRQs are faster, but the difference was very slight last time someone actually measured, I do believe.) It depends on what machine you stick that Phobos card in, anyway. The Compaqs I've stuck 'em in give 'em shared IRQs, (Celeron 300) ppb1 at pci0 dev 13 function 0 DEC 21152 PCI-PCI rev 0x03 pci2 at ppb1 bus 2 dc0 at pci2 dev 4 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2c lxtphy0 at dc0 phy 1: LXT971 10/100 PHY, rev. 1 dc1 at pci2 dev 5 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2d lxtphy1 at dc1 phy 1: LXT971 10/100 PHY, rev. 1 dc2 at pci2 dev 6 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2e lxtphy2 at dc2 phy 1: LXT971 10/100 PHY, rev. 1 dc3 at pci2 dev 7 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2f lxtphy3 at dc3 phy 1: LXT971 10/100 PHY, rev. 1 (I'm sure not all Compaqs do that, but I seem to have a pile of P90 through PII-450s that seem to only allocate one IRQ to the PCI bus, only thing in common between them is the Compaq badge on the front. This machine had at least two other devices sharing that same IRQ 11. Put four fxp cards in there, you will see them all on IRQ 11, too). however, the same kind of card in this Dell does not: (Celeron 400) ppb1 at pci0 dev 13 function 0 DEC 21152 PCI-PCI rev 0x03 pci2 at ppb1 bus 2 dc0 at pci2 dev 4 function 0 DEC 21142/3 rev 0x41: irq 9, address 00:60:f5:08:54:20 lxtphy0 at dc0 phy 1: LXT971 10/100 PHY, rev. 1 dc1 at pci2 dev 5 function 0 DEC 21142/3 rev 0x41: irq 10, address 00:60:f5:08:54:21 lxtphy1 at dc1 phy 1: LXT971 10/100 PHY, rev. 1 dc2 at pci2 dev 6 function 0 DEC 21142/3 rev 0x41: irq 5, address 00:60:f5:08:54:22 lxtphy2 at dc2 phy 1: LXT971 10/100 PHY, rev. 1 dc3 at pci2 dev 7 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:23 lxtphy3 at dc3 phy 1: LXT971 10/100 PHY, rev. 1 (I'll spare you the dmesg from the five 4port NIC dell I set up. Needless to say, IRQs were shared. :) So, if you have to switch between different HW to get shared vs. personal IRQs, you have changed a lot more variables... You will see a much bigger difference about the different chips you have (dc vs. fxp, or even which fxp version you get). Probably even bigger than that would be the design of the machine -- if you have a machine where each individual NIC is on a separate PCI bus, you may see better performance than having them all on one bus (like you would on the quad-port card). HOWEVER... *IF* you really have a situation where you would really see a performance difference between the Phobos and four fxps, you probably need to say, WRONG CARD and grab some good gigabit NICs instead. This isn't auto racing, no one will ever notice a percent or two difference in performance. If you got to use a stopwatch or benchmark to see the difference, it's wasted effort. To get any real difference, you will need some (even) better NICs. Nick.
Re: via 8231 and 8237
On Thu, Oct 20, 2005 at 11:13:07AM -0400, Michael Shalayeff wrote: re everybody who experienced problems w/ the mention chipsets on the mobos such as audio not interrupting properly and stuff. please try the changes i just put into sys/arch/i386/pci/. (suppose bias according to your local mirror update). I don't noticed any problems except that the identification/mapping failed but now all is fine (-current amd64): pcib0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 Thanks and regards Simon
Re: DISKLESS tutorial that need feedback
Bachman Kharazmi wrote: Please STOP the discussion about document formats in this thread. You're taking my time complaing on the document format (pdf). In my first post I wrote that I want feedback on the document and nothing else. I understand your frustation that your thread has been hijacked. If your computer can't run any pdf reader that's your problem. So please stop asking if I can make any HTML or other formats. There are several pdf readers in the ports tree, for those that is interested. Others have given comments to your document, so here is a little nitpick: You may use mkdir with -p option to create intermediate directories instead of creating each and everyone of them explicitely. /Sigfred
re* broken on OpenBSD 3.8 -current?
Hi guys, Just wanted to mention that during installation of last snapshot from openbsd.informatik.uni-erlangen.de, when it's time to configure the gigabit ethernet card with DHCP the following message appears: re0: watchdog timeout re0: watchdog timeout re0: watchdog timeout eventually it does get an IP address from the gateway, but then, during ftp installation: re0: watchdog timeout re0: watchdog timeout re0: watchdog timeout re0: watchdog timeout ftp: connect to address 2001:638:a00:f008::1: No route to host re0: watchdog timeout re0: watchdog timeout re0: watchdog timeout ... At nauseam :o This machine ran fine on OpenBSD 3.8 -current from about 5-6 days ago. Specs: MSI K8T Neo-V (MS-7032) Version 1 AMD Sempron 3000+ (Socket 754) Kingston ValueRAM PC3200 (512Mb) Western Digital WD1600JS-88MHB0 US Robotics Gigabit Ethernet card If interested I have a DMESG from September 29 on OpenBSD 3.8 current. Thanks, P
Re: DISKLESS tutorial that need feedback
On 10/23/05, Sigfred Heversen [EMAIL PROTECTED] wrote: Bachman Kharazmi wrote: Please STOP the discussion about document formats in this thread. You're taking my time complaing on the document format (pdf). In my first post I wrote that I want feedback on the document and nothing else. I understand your frustation that your thread has been hijacked. If your computer can't run any pdf reader that's your problem. So please stop asking if I can make any HTML or other formats. There are several pdf readers in the ports tree, for those that is interested. Others have given comments to your document, so here is a little nitpick: You may use mkdir with -p option to create intermediate directories instead of creating each and everyone of them explicitely. The doc is updated. Thanks alot. /bkw
Re: OpenOffice.org 2.0 works on OpenBSD
Hi, A little while back I got OpenOffice.org 2.0 to work on OpenBSD 3.8 snapshots. I didn't use the linux proc and I didn't install the RPM's. I used rpm2cpio to convert the RPM's, then I used cpio to extract the achives. I enabled linux emulation and then just ran the soffice.bin file. Everything works perfect on my machine. I have done some testing with previous written documentation in OpenOffice.org 1.5 and everything has been working perfectly. Best regards, Rico
root on raidframe
Greets: I've been exploring root on raidframe w/a pair of mirrored disks. Once I bring something like this up I then go ahead and do my best to break it, test out recovery scenarios, etc. Which brings me to the question at hand. Following a hard failure the system must perfomr a parity check on the raid volume(s) prior to fsck'ing and completing booting. Depending on disk size, speed, and number of volumes, this can easly require a few hours of wait time before being able to bring the system back online. Now my question is whether there is some way to shorten this delay that I'm missing? TIA-- -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon?
Re: OpenBSD MetaStore: Distributed hosting?
Please guys, can we stop this fight over who does what and how to be accessible from where. In the interest of bringing peace back on misc@ I will extend the offer to host this on high capacity network if the community really want it. More then once the community always say, yes this is great, we need that, why don't we have this, and someone should do it! So far, each time this happened, it was more wind talks then anything else and never was pursue for real! With few exceptions to be fully honest to some really brave sole that actually step in here and contribute something! But in every case, the wind blow and then the leafs fall on the ground to leave empty trees that never see the spring again! If you really want it and if that is useful to some, I will offer to make it available to EVERYONE! But, please understand this! STOP bugging the project with these things, they do what they do best and they don't need this to improve our beloved OS! So trying to make that part of the official project is really waisting everyone times. And finally, no hardware company, or very few if you search the archive ever contribute back to the project, so if you think this might become a source of income for the project it's really an utopia! You want the project to get more income, well as far as I know, it's there: http://openbsd.org/donations.html Just give, to think you can setup something that will turn into a source of income and that the project will take under it's wing is having it's eyes close and not knowing that no one will step to actually do it and make it work and the dev's HAVE other things to do, nor do they are interested to do this! Don't forget, they do this OS for themselves and offer us the benefit to use it! They don't need a site providing supported hardware for them to see what they should use or have! For crying at loud! If they like some hardware and it's not working for them! How long do you think it will take them to make it work on it if really they want it, hmmm!!! Do you think they will even care about what's supported or not!!! Think about it for a few seconds and you will have your answer! Looked at the Sharp Zaurus C3000 PDAs It was a new CPU and OpenBSD wasn't design for it at all, but hey, they like that little box, so how long did it really take them!? If they want it, they don't need any of us to tell them what hardware it might work on! If they want it really badly, they will simply make it work for themselves!!! So, I am done. I really didn't want to fall into answering this tread, but here I did, shame on me for doing it! I will not answer more on this list either for this tread. If some of you want this moved, or hosted else where, or provide me the data to make it public, I will be more then happy to do so, but do it off list and lets stop this fight here please! Can we do that? I waisted way to much of everyone times already! Sorry for doing so! Now NO ONE have any reason to continue complaining about this anymore. You want this else where fully accessible, I make the offer to do it in the interest of peace! So, either put up of shut up!!! What will it be? Your move next! And lets take it off list please! Best regards, Daniel
Re: root on raidframe
On 10/23/05, Ken Gunderson [EMAIL PROTECTED] wrote: Now my question is whether there is some way to shorten this delay that I'm missing? Did you read through the list archives? This matter is well-discussed. Other OS'es, such as NetBSD, use a different way for the checking of parity (i.e. in the background). The caveats with this approach are listed in the man pages for raidctl(8) and raid(4). Cheers, Rogier -- If you don't know where you're going, any road will get you there.
Re: external interface of a bridge not filtering for itself
generally with a filtering bridge, you would want to pass all traffic
on one of the interfaces ('set skip on XX' or a 'pass on XX' rule), and
just make rules apply to the other interface. Whether or not this is
what you're doing, isn't clear from your message.
Thanks. Determinable from this data? It seems like set skip
should be like quick, that filtering applies only to vge0.
-
# brconfig -a
bridge0: flags=41UP,RUNNING
Configuration:
priority 32768 hellotime 2 fwddelay 15 maxage 20
Interfaces:
vge0 flags=3LEARNING,DISCOVER
port 1 ifpriority 128 ifcost 55
dc0 flags=3LEARNING,DISCOVER
port 2 ifpriority 128 ifcost 55
Addresses (max cache: 100, timeout: 240)
--
# netstat -rn -finet
Routing tables
Internet:
DestinationGatewayFlags Refs UseMtu Interface
default70.84.X.1 UGS 05 - dc0
127/8 127.0.0.1 UGRS00 33224 lo0
127.0.0.1 127.0.0.1 UH 10 33224 lo0
70.84.X.0/25 link#2 UC 30 - dc0
70.84.x.1 0:17:61:31:2b:a0 UHLc10 - dc0
70.84.X.15 0:c0:a5:43:c:c5UHLc1 46 - dc0
224/4 127.0.0.1 URS 00 33224 lo0
-
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224
groups: lo
inet 127.0.0.1 netmask 0xff00
pflog0: flags=141UP,RUNNING,PROMISC mtu 33224
pfsync0: flags=0 mtu 1348
enc0: flags=0 mtu 1536
vge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
media: Ethernet autoselect (100baseTX full-duplex)
status: active
dc0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 70.84.x.16 netmask 0xff80 broadcast 70.84.x.127
bridge0: flags=41UP,RUNNING mtu 1500
groups: bridge
---
pf.conf
ext_if = vge0
int_if = dc0
icmp_types = echoreq
table ntp { 152.2.21.1 128.2.136.71 }
table dns { 192.107.x.34 192.107.x.21 }
table this { 70.84.x.15 }
set loginterface none
set optimization normal
set block-policy drop
set require-order yes
set skip on { lo $int_if }
scrub in
block in on $ext_if
block out on $ext_if
antispoof quick for { lo $int_if }
pass in quick on $ext_if inet proto { udp tcp } \
from dns to this keep state
pass in quick on $ext_if inet proto udp \
from ntp to this port { 123 } keep state
pass in on $ext_if inet proto icmp all \
icmp-type $icmp_types keep state
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state
Darrel
Re: external interface of a bridge not filtering for itself
--On 23 October 2005 16:52 -0400, [EMAIL PROTECTED] wrote:
generally with a filtering bridge, you would want to pass all
traffic on one of the interfaces ('set skip on XX' or a 'pass on
XX' rule), and just make rules apply to the other interface.
Whether or not this is what you're doing, isn't clear from your
message.
Thanks. Determinable from this data? It seems like set skip
should be like quick, that filtering applies only to vge0.
Much better, thanks. This clears up eth_if vs. ext_if from your
original post too.
dc0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu
1500 groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 70.84.x.16 netmask 0xff80 broadcast 70.84.x.127
set skip on { lo $int_if }
You have placed the IP address on dc0, which is $int_if in pf.conf,
which you are skipping in pf. Either try moving the IP address to vge0,
or change the rules to work on the other interface.
Email problems
Hi all, Until 4 days ago, I no longer receive email on my server. I thought it was my provider (cox) since they block inbound and outbound smtp. When I send email from the outside, nothing shows up in my /var/mail/maillog, I then get an email 3 days later connection timed out with my server. If I send locally to verify pop and imap os working, no problem what so ever. If I telnet from the outside to my server on port 110 143, $ telnet whywire.com 110 Trying 68.227.194.65... Connected to whywire.com. Escape character is '^]'. +OK quit +OK Connection closed by foreign host. $ telnet whywire.com 143 Trying 68.227.194.65... Connected to whywire.com. Escape character is '^]'. * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=LOGIN] marvin.whywire.com IMAP4rev1 2004.357 at Sun, 23 Oct 2005 14:12:08 -0400 (EDT) This problem started 4 days ago and I didn't apply any modification on the server. What else can I look for? Thank you.
Re: Email problems
On 10/23/05, Monah Baki [EMAIL PROTECTED] wrote: Until 4 days ago, I no longer receive email on my server. I thought it was my provider (cox) since they block inbound and outbound smtp. In the first case, you're out of luck unless you find an external party that can relay your e-mail to you through a different port. In the latter case, only outbound e-mail is affected. Please note that this situation makes your problem rather more ISP-related than OpenBSD-related. If I send locally to verify pop and imap os working, no problem what so ever. You shouldn't limit your checks to the pop3 and imap ports. E-mail is delivered first through SMTP; your MTA will handle it from there (e.g. allow access through POP3 and/or IMAP). Check whether external servers can connect to your smtp port. If they can't, the timeout is quite easy to explain. Cheers, Rogier -- If you don't know where you're going, any road will get you there.
Re: external interface of a bridge not filtering for itself
On Sunday 23 October 2005 05:58 pm, Stuart Henderson wrote:
--On 23 October 2005 16:52 -0400, [EMAIL PROTECTED] wrote:
generally with a filtering bridge, you would want to pass all
traffic on one of the interfaces ('set skip on XX' or a 'pass on
XX' rule), and just make rules apply to the other interface.
Whether or not this is what you're doing, isn't clear from your
message.
Thanks. Determinable from this data? It seems like set skip
should be like quick, that filtering applies only to vge0.
Much better, thanks. This clears up eth_if vs. ext_if from your
original post too.
dc0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu
1500 groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 70.84.x.16 netmask 0xff80 broadcast 70.84.x.127
set skip on { lo $int_if }
You have placed the IP address on dc0, which is $int_if in pf.conf,
which you are skipping in pf. Either try moving the IP address to vge0,
or change the rules to work on the other interface.
I moved the IP address to vge0. Fixed. I trust that authlog will look better
now.
Thanks!
Darrel
Re: Intel 6300ESB SATA
On Sun, Oct 23, 2005 at 05:15:29PM -0600, Sibastien Taylor wrote: I am having problems having two SATA disks recognized by OpenBSD, the 6300ESB controller is found and seems to be configured properly but I get the error: pciide2: couldn't map channel 0 cmd regs pciide2: couldn't map channel 1 cmd regs I'm assuming that this is from failing to DMA map the two SATA disks? This controller is listed as supported in pciide(4) and I see no mention of issues of DMA or otherwise with this chipset though I did see someone mention that it caused a system hang in 3.5 though that obviously seems to be fixed now since this system is stable and install successfully onto a standard PATA disk. My dmesg is bellow, any help would be greatly appreciated. Give this diff a go. Index: pciide.c === RCS file: /cvs/src/sys/dev/pci/pciide.c,v retrieving revision 1.216 diff -u -p -r1.216 pciide.c --- pciide.c22 Oct 2005 23:13:26 - 1.216 +++ pciide.c23 Oct 2005 23:58:08 - @@ -2063,6 +2063,8 @@ chansetup: /* SATA setup */ if (sc-sc_pp-ide_product == PCI_PRODUCT_INTEL_82801EB_SATA || sc-sc_pp-ide_product == PCI_PRODUCT_INTEL_82801ER_SATA || + sc-sc_pp-ide_product == PCI_PRODUCT_INTEL_6300ESB_SATA || + sc-sc_pp-ide_product == PCI_PRODUCT_INTEL_6300ESB_SATA2 || sc-sc_pp-ide_product == PCI_PRODUCT_INTEL_82801FBM_SATA || sc-sc_pp-ide_product == PCI_PRODUCT_INTEL_82801FB_SATA || sc-sc_pp-ide_product == PCI_PRODUCT_INTEL_82801FR_SATA ||
Re: ipmi(4)
Marco Peereboom wrote: Folks who keep track of cvs changes might have noticed a barrage of commits regarding ipmi(4). The driver is functionally complete but needs wide testing on both amd64 and i386 architectures. Jordan Hargrave (jordan@) wrote most of the code. Let's talk a bit about ipmi(4). What is it anyway? The ipmi term Intelligent Platform Management refers to autonomous monitoring and recovery features implemented directly in platform management hardware and firmware. The key characteristics of Intelligent Platform Management is that inventory, monitoring, logging, and recovery control functions are available independent of the main processor, BIOS, and operating system. (much more in ipmi(4)!) If your box supports IPMI you'll see a similar line in dmesg. ipmi0 at mainbus0: version 1.0 interface SMIC iobase 0xecf4/3 spacing 1 Great, now how does that help me? The driver retrieves ipmi readings and publishes them via the sysctl interface. Here is the output of a Dell PowerEdge 2650: # sysctl hw.sensors hw.sensors.0=ipmi0, ESM Frt I/O Temp, OK, temp, 24.00 degC / 75.20 degF hw.sensors.1=ipmi0, ESM Riser Temp, OK, temp, 26.00 degC / 78.80 degF hw.sensors.2=ipmi0, ESM CPU 1 Temp, OK, temp, 26.00 degC / 78.80 degF hw.sensors.3=ipmi0, ESM MB Bat Volt, OK, volts_dc, 3.18 V hw.sensors.4=ipmi0, ESM 3.3 FP Volt, OK, volts_dc, 3.23 V hw.sensors.5=ipmi0, ESM MB 3.3 Volt, OK, volts_dc, 3.27 V hw.sensors.6=ipmi0, ESM MB 5 Volt, OK, volts_dc, 4.99 V hw.sensors.7=ipmi0, ESM CPU Volt, OK, volts_dc, 1.47 V hw.sensors.8=ipmi0, ESM MB +12 Volt, OK, volts_dc, 11.90 V hw.sensors.9=ipmi0, ESM MB -12 Volt, OK, volts_dc, -11.97 V hw.sensors.10=ipmi0, ESM MB 2.5 Volt, OK, volts_dc, 2.52 V hw.sensors.11=ipmi0, ESM GB0 2.5 Volt, OK, volts_dc, 2.56 V hw.sensors.12=ipmi0, ESM GB1 2.5 Volt, OK, volts_dc, 2.56 V hw.sensors.13=ipmi0, ESM 5 AUX Volt, OK, volts_dc, 5.11 V hw.sensors.14=ipmi0, ESM ROMB PK Volt, OK, volts_dc, 3.96 V hw.sensors.15=ipmi0, ESM GB0 1.2 Volt, OK, volts_dc, 1.21 V hw.sensors.16=ipmi0, ESM GB1 1.2 Volt, OK, volts_dc, 1.22 V hw.sensors.17=ipmi0, ESM VTT Volt, OK, volts_dc, 1.27 V hw.sensors.18=ipmi0, ESM MB Fan1 RPM, OK, fanrpm, 4740 RPM hw.sensors.19=ipmi0, ESM MB Fan2 RPM, OK, fanrpm, 4800 RPM hw.sensors.20=ipmi0, ESM MB Fan4 RPM, OK, fanrpm, 7500 RPM hw.sensors.21=ipmi0, ESM MB Fan6 RPM, OK, fanrpm, 7140 RPM hw.sensors.22=ipmi0, ESM MB Fan7 RPM, OK, fanrpm, 7020 RPM hw.sensors.23=ipmi0, Power Supply - 1, OK, indicator, On hw.sensors.24=ipmi0, Power Supply - 2, CRITICAL, indicator, Off hw.sensors.25=ipmi0, Cover Intrusion, OK, indicator, Off hw.sensors.26=ipmi0, Bezel Intrusion, OK, indicator, Off hw.sensors.27=safte0, temp0, OK, temp, 22.78 degC / 73.00 degF hw.sensors.28=safte0, temp1, OK, temp, 24.44 degC / 76.00 degF Lots of stuff! In the list you'll find core voltage measurements, fan speeds, power supply readings etc. As you can see I do not have a 2nd power supply in this box. Nifty, now lets open up the chassis and see what happens. hw.sensors.25=ipmi0, Cover Intrusion, CRITICAL, indicator, On As you can see the Cover Intrusion went to critical. Now lets pull a fan. hw.sensors.18=ipmi0, ESM MB Fan1 RPM, CRITICAL, fanrpm, 0 RPM hw.sensors.19=ipmi0, ESM MB Fan2 RPM, OK, fanrpm, 7980 RPM hw.sensors.20=ipmi0, ESM MB Fan4 RPM, OK, fanrpm, 7380 RPM hw.sensors.21=ipmi0, ESM MB Fan6 RPM, OK, fanrpm, 7140 RPM hw.sensors.22=ipmi0, ESM MB Fan7 RPM, OK, fanrpm, 7020 RPM Fan1 went critical but also the speed of Fan2 went up to compensate. Lets pull another fan. hw.sensors.18=ipmi0, ESM MB Fan1 RPM, CRITICAL, fanrpm, 0 RPM hw.sensors.19=ipmi0, ESM MB Fan2 RPM, OK, fanrpm, 7980 RPM hw.sensors.20=ipmi0, ESM MB Fan4 RPM, CRITICAL, fanrpm, 0 RPM hw.sensors.21=ipmi0, ESM MB Fan6 RPM, OK, fanrpm, 7200 RPM hw.sensors.22=ipmi0, ESM MB Fan7 RPM, OK, fanrpm, 7020 RPM Now lets stick them back in. hw.sensors.18=ipmi0, ESM MB Fan1 RPM, OK, fanrpm, 4740 RPM hw.sensors.19=ipmi0, ESM MB Fan2 RPM, OK, fanrpm, 4800 RPM hw.sensors.20=ipmi0, ESM MB Fan4 RPM, OK, fanrpm, 7320 RPM hw.sensors.21=ipmi0, ESM MB Fan6 RPM, OK, fanrpm, 7140 RPM hw.sensors.22=ipmi0, ESM MB Fan7 RPM, OK, fanrpm, 7020 RPM Ah look at that, both fans are happy again and Fan2 slowed down. Lets put the cover back on. hw.sensors.25=ipmi0, Cover Intrusion, OK, indicator, Off And the box is all happy again. Combine this with sensorsd(8) and you can have email, pagers, sirens, fog horns and other alerting mechanisms go off. What's next? We'll continue to add sensor types that make sense to report. Another thing that needs to happen is the reporting of threshold values and a mechanism to change these values. All that is in the future though. Cool, what can I do? Test! We need wide testing on systems that have IPMI. I bet there has to be some tuning to work around timing differences between platforms. The current code was tested on Intel, Dell and Sun boards.
Re: root on raidframe
On Sun, 23 Oct 2005 22:43:26 +0200 Rogier Krieger [EMAIL PROTECTED] wrote: On 10/23/05, Ken Gunderson [EMAIL PROTECTED] wrote: Now my question is whether there is some way to shorten this delay that I'm missing? Did you read through the list archives? This matter is well-discussed. Other OS'es, such as NetBSD, use a different way for the checking of parity (i.e. in the background). For the record I am a pretty experienced *nix sysadmin and typically do my homework reasonably thoroughly before asking others for help. Admittedly I did not read every post and there are times when even the best of us miss the obvious. But let me assure you that I did look. I'm not familiar w/NetBSD. I also do not recall encountering any references to background parity checking in the man pages. Am I correct in assuming you're refernecing the rc raidctl -P all hack?? Or did you have something else in mind? Since it's apparent to me that: 1) having such a long wait after a hard crash is suboptimal 2) OBSD is an excellent and mature *nix 3) and many others have gone before me 4) Despite being a legend in my own mind, I may well have missed something. So I am braving the legendary wrath of misc and inquiring. If you could provide a pointer I'd appreciate it. There's a lot of posts, not always labeled w/ the most appropriate subject. The caveats with this approach are listed in the man pages for raidctl(8) and raid(4). I have read the man pages. More than once. For example, I read this in raid (4) Recomputation of parity MUST be performed whenever there is a chance that it may have been compromised. This includes after system crashes, or be- fore a RAID device has been used for the first time. Failure to keep... And then again in raidctl (8): Recomputation of parity MUST be performed whenever there is a chance that it may have been compromised. This includes after system crashes Now I take MUST written in all caps as really meaning MUST. So that makes me shy away from the /etc/rc hack. This is a root on raid configuration. So when the system boots the raidsets are configured automatically. Boot needs to complete before I have access to tools such as raidctl to turn off auto. Now it occurs to me that I could just pull one of the drives after a hard failure. Then the parity check would get short circuited, the missing drive failed as component 1 and the raidset marked dirty, and the system would come up much quicker. Then proceed w/ a raidctl - R followed by a raidctl - P. Which seems an awful hack on par with backgrounding the parity check in /etc/rc. Other than these two hacks, however, it eludes me. And since the theme of the 3.8 release is Hackers of the Lost Raid, I am wondering if OBSD might have something slick up it's sleve that might not be too well documented as of yet. Suggestions and pointers welcome. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon?
Re: root on raidframe
Ken Gunderson wrote: Greets: I've been exploring root on raidframe w/a pair of mirrored disks. Once I bring something like this up I then go ahead and do my best to break it, test out recovery scenarios, etc. smart. VERY smart. :) Which brings me to the question at hand. Following a hard failure the system must perfomr a parity check on the raid volume(s) prior to fsck'ing and completing booting. Depending on disk size, speed, and number of volumes, this can easly require a few hours of wait time before being able to bring the system back online. Now my question is whether there is some way to shorten this delay that I'm missing? yes. RAIDframe as absolutely little as you NEED to. Soft-mirroring (or hardware-mirroring, for that matter) more than you absolutely need to is foolish. Let's look at a simple mail server for an example (since you didn't describe your app): / /usr /var /home /var/mail /tmp Where does stuff change rapidly and critical to not lose even a minute's worth of change if possible? /var/mail, probably. MAYBE /home. So, RAIDframe those. / ? Use the altroot process for that. /usr ? dump/restore it to a second disk nightly or weekly. /tmp ? well, as I'm basically assuming your system is going down if a drive fails, I'm going to argue that /tmp does not need to be mirrored. You probably don't need to be mirroring your /usr/src, /usr/ports or /usr/obj directories, even if you really DID want to mirror /, /usr, /tmp, and friends. Now, after an event, only /var/mail (and maybe /home) have to be rebuilt. One nice thing about RAIDframe (or ccd(4)) is that you can mirror only a little slice of a big drive if you so desire. Even if you want to keep the entire system mirrored, you could probably get away with a 2G or 600M system for a lot of applications, rather than 80G or whatever the smallest disk you can get now is. With HW mirroring, you end up doing the entire 80G (or 250G when the purchasing dept. says, hey, it was only $20 more, so we got the bigger one!) Yes, it isn't The Solution for all situations, but it helps in a lot of places. Nick.
Re: ipmi(4)
per engelbrecht wrote: This is really (really) great news. Been blasting through a few servers but so fare, unfortunately, without any ipmi? in any of the dmesg. Will try the bigger irons in a few hours. Looking forward to using it though. Thank you guys. I haven't had a chance to test it yet, but most HP (pre-Compaq) servers have IPMI support.
Re: root on raidframe
On Sun, 23 Oct 2005 22:42:35 -0400 Nick Holland [EMAIL PROTECTED] wrote: Ken Gunderson wrote: Greets: I've been exploring root on raidframe w/a pair of mirrored disks. Once I bring something like this up I then go ahead and do my best to break it, test out recovery scenarios, etc. smart. VERY smart. :) Thnx;-) Which brings me to the question at hand. Following a hard failure the system must perfomr a parity check on the raid volume(s) prior to fsck'ing and completing booting. Depending on disk size, speed, and number of volumes, this can easly require a few hours of wait time before being able to bring the system back online. Now my question is whether there is some way to shorten this delay that I'm missing? yes. RAIDframe as absolutely little as you NEED to. Soft-mirroring (or hardware-mirroring, for that matter) more than you absolutely need to is foolish. Let's look at a simple mail server for an example (since you didn't describe your app): The application in this case is a routing firewall/proxy server for a 3 legged network configuration. Resources to implement a carp setup are not available. The objective for the system: 1) to be as self healing as possible 2) minimize downtime resulting from this single point of failure failing 3) maximiz capability for remote system management 4) minimizing requrement for assistance from on site personnel. /home, /tmp and /var/tmp are inconsequential. No users on this system. But the system will be doing smtp relaying and in the unlikely event some malicious type was able to induce obsd to crash I'd like to have the packets logged... Logging to remote machine is good practice but not an option at present. So we've got a large /var on this puppy. Hence the long wait. Otherwise if just for perimeter firewall/router a diskless setup would probably be best. I've done some testing w/the /etc/rc backgound parity hack and the box comes up after a hard failure in about 1/2 hour. Which isn't too bad compared to the 1.5 -2 hours otherwise. For the sake of experimentation the raid conf is presently: 512M / mirror 2048M swap stripped couple hundred gigs mirrored for everything else. Thanks for your insights. Appreciate the constructive input. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon?
