machdep.allowaperture=1 setting is safer?
Hello All I have a Intel Core2Duo desktop (dmesg attached below) running fully patched i386 4.6 GENERIC.MP. xdriinfo and glxinfo o/p doesn't change whether machdep.allowaperture is set to 1 or 2. And X is fully functional/stable in both cases as it has been for the past 6 months (with 4.5-stable too). xf86(4) seemed to suggest 1 is better security-wise than 2, and that led me to try this setting. glxgears gives the same 247 fps for both settings. In this light, is it more secure to us 1 than 2 and am I missing some functionality of my hardware in the process? Could someone please clarify. Yours Srikant. OpenBSD 4.6 (GENERIC.MP) #1: Thu Oct 29 09:04:24 IST 2009 root@:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (GenuineIntel 686-class) 3.02 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR real mem = 3747770368 (3574MB) avail mem = 3639156736 (3470MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 05/22/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xf06b0 (49 entries) bios0: vendor American Megatrends Inc. version 0411 date 05/22/2009 bios0: ASUSTeK Computer INC. P5KPL-AM/PS acpi0 at bios0: rev 0 acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) EUSB(S4) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 334MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (GenuineIntel 686-class) 3.02 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (P0P1) acpiprt2 at acpi0: bus 2 (P0P4) acpiprt3 at acpi0: bus 1 (P0P5) acpiprt4 at acpi0: bus -1 (P0P6) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB bios0: ROM list: 0xc/0xb400! cpu0: Enhanced SpeedStep 3011 MHz: speeds: 2997, 1998 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82G33 Host rev 0x10 vga1 at pci0 dev 2 function 0 Intel 82G33 Video rev 0x10 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 (irq 10) drm0 at inteldrm0 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x01: apic 2 int 16 (irq 10) azalia0: codecs: Realtek ALC662 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 2 int 16 (irq 10) pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x01: apic 2 int 17 (irq 11) pci2 at ppb1 bus 1 re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x02: RTL8168C/8111C (0x3c00), apic 2 int 17 (irq 11), address 00:24:8c:e9:45:fd rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 2 int 23 (irq 5) uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 2 int 19 (irq 10) uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 2 int 18 (irq 11) uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 2 int 16 (irq 10) ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 2 int 23 (irq 5) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci3 at ppb2 bus 3 vr0 at pci3 dev 0 function 0 VIA VT6105 RhineIII rev 0x8b: apic 2 int 19 (irq 10), address 00:21:91:8d:e8:be ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 9: OUI 0x004063, model 0x0034 ichpcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01: PM disabled pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) pciide1 at pci0 dev 31 function 2 Intel 82801GB SATA rev 0x01: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using apic 2 int 19 (irq 10) for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: ST3500418AS wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 ichiic0 at pci0 dev 31 function 3 Intel 82801GB SMBus rev 0x01: apic 2 int 19 (irq 10) iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR2
Re: Partitioning an external USB drive through OpenBSD -- disklabel
On Fri, Oct 30, 2009 at 08:48:47PM -0400, Tony Abernethy wrote: Sorry for top-posting, but please: Disk sectors start with 1 (unless you are reformatting the entire track and something like Write Record zero still exists) On DOS-FORMATTED disks, the initial sector is at cylinder 0, head 0, sector 1, and contains within the bootstrap loader what DOS and Windows calls a Partition Table. The rest of track 0 is empty, unless you are running a boot sector virus or such. Sorry for not using weird DOS counting system. From the kernel point of view sectors start at 0. MBR CHS info presentation is irrelevant. And the kernel uses LBA anyway. And the rest of track 0 can be used if you so desire. It used to get the disklabel more frequently than it currently does. Ken -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Kenneth R Westerback Sent: Friday, October 30, 2009 5:38 PM To: Josh Grosse Cc: Amarendra Godbole; misc Subject: Re: Partitioning an external USB drive through OpenBSD -- disklabel On Fri, Oct 30, 2009 at 08:53:45AM -0500, Josh Grosse wrote: On Fri, 30 Oct 2009 18:44:08 +0530, Amarendra Godbole wrote Thank you all for responses -- I have a better idea now. The only thing that I noticed was newfs_msdos wipes out the entire disklabel as well as any fdisk created partitions and gobbles up the entire disk. I guess what James Hartley said in this thread is correct -- Windows must be used to create the DOS partition, and then disklabel to get the OpenBSD one. No, the reason the MBR and disklabel were wiped out was due to an error you made: starting the partition at sector #0. That sector contians the MBR and the MBR primary partition table, and the OpenBSD disklabel follows behind. Normally, one would begin the first partition -after- the first track (typically sectors 0-62). But, If you were to use Windows disk management to create a FAT partition of some size on the disk, Windows will begin it at sector #63 for you. Knowledge of disk geometry and usage is not required by a Windows user, as the tools do not allow you the control that fdisk(8) does. On MBR formatted disks, sector 0 is the MBR. So overwriting that will indeed toast important information about the disk. However the OpenBSD disklabel is not written to the sector after the MBR if there is an OpenBSD partition, it is written to the second sector of the first OpenBSD partition. So whacking the MSDOS partition starting at sector 0 toasts the MBR, which means the OpenBSD partition cannot be found, which means the disklabel is inaccessable. If you were to re-create the MBR with the correct partitions, the disklabel would re-appear. The MSDOS parition would now be broken of course. :-). As an example here is one of my disks, and a hexdump of the first 65 sectors. The MBR can be seen at sector 0, and the disklabel at sector 64. (64*512 = 32768 = 0x8000). You'll have to take my word I did dd if=/dev/rsd0c of=~/tmp/sect0to64 bs=512 count=65 hexdump -C ~/tmp/sect0to64 ~/tmp/sect0to64.txt Ken Script started on Fri Oct 30 18:11:16 2009 # fdisk sd0 Disk: sd0 geometry: 38913/255/63 [625142448 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 1 - 38912 254 63 [ 63: 625137282 ] OpenBSD # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: WDC WD3200AAKS-0 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 38913 total sectors: 625142448 rpm: 3600 interleave: 1 boundstart: 63 boundend: 625137345 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 417627 63 4.2BSD 2048 163841 # / b: 25173855 417690swap c:6251424480 unused d: 417690 25591545 4.2BSD 2048 163841 # /tmp e: 417690 26009235 4.2BSD 2048 163841 # /var g: 20980890 26426925 4.2BSD 2048 163841 # /usr h:514786860110350485 4.2BSD 2048 163841 # /home i: 20980890 47407815 4.2BSD 2048 163841 # /usr/src j: 20980890 68388705 4.2BSD 2048 163841 # /usr/ports k: 20980890 89369595 4.2BSD 2048 163841 # /usr/xenocara # cat sect0to64.txt ea 05 00 c0 07 8c c8 8e d0 bc fc ff 8e d8 b8 a0 |j...@..h.p|.X8 |
Re: Partitioning an external USB drive through OpenBSD -- disklabel
Sorry for top-posting, but please: Disk sectors start with 1 Just pathetic. Hope you actually get a life sometime.
Re: machdep.allowaperture=1 setting is safer?
On Sat, Oct 31, 2009 at 6:57 AM, srikant@gmail.com wrote: Hello All I have a Intel Core2Duo desktop (dmesg attached below) running fully patched i386 4.6 GENERIC.MP. xdriinfo and glxinfo o/p doesn't change whether machdep.allowaperture is set to 1 or 2. And X is fully functional/stable in both cases as it has been for the past 6 months (with 4.5-stable too). xf86(4) seemed to suggest 1 is better security-wise than 2, and that led me to try this setting. glxgears gives the same 247 fps for both settings. In this light, is it more secure to us 1 than 2 and am I missing some functionality of my hardware in the process? Could someone please cl see xf86(4). And yes the xf86-video-intel driver doesn't need the int10 emulation anymore so in this case '1' is enough to get it working '2' is needed by X.Org drivers that rely on the int10 emulation to get things setup through the bios of the card. -- Matthieu Herrb
umask for remote host in sftp / sftp-server
How can umask be set on the remote host for chrooted sftp users? I'm having trouble guessing how to set umask for sftp users on the remote system. AFAIK, it is usually function of the shell, which is not used by the sftp client. ~/.cshrc, ~/.profile, and ~/.login seem to not affect sftp, nor did /etc/csh.cshrc or /etc/csh.login A workaround for non-chroot sftp: If the sftp user authenticated using a key, then the key in the ~/.ssh/authorized_keys file can be modified with this: command=umask 0002;/usr/libexec/sftp-server; but that constrains that key to sftp use only and no ssh action. That work-around, obviously, won't work in the chrooted sftp. /Lars
Re: umask for remote host in sftp / sftp-server
On Saturday 31 October 2009 10.13.44 you wrote: How can umask be set on the remote host for chrooted sftp users? [...] Setup a umask for your users' class in login.conf(5). Perhaps add them in a new class, eg.: master.passwd(5): user:*:1001:1001:sftp:0:0::/home/user:/bin/ksh login.conf(5): sftp:\ :umask=027:\ :tc=default: Daniel -- LIVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: machdep.allowaperture=1 setting is safer?
On 31 October 2009 c. 10:47:31 Matthieu Herrb wrote: '2' is needed by X.Org drivers that rely on the int10 emulation to get things setup through the bios of the card. And how can user easily detect that a driver rely on int10 emulation? Or no one should bother as the drivers will get fixed eventually? BTW, does anyone know if any other (X?) programs require '2', and in which cases? mplayer? -- Best wishes, Vadim Zhukov A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
NFS client hang.
Hi, I'm using OpenBSD 4.6 GENERIC on a alix 2D3 board with a compact flash card mounted as ffs. wd0 at pciide0 channel 0 drive 0: CF CARD 4GB wd0: 1-sector PIO, LBA, 3831MB, 7847280 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 I try to use remote NFS directory for /usr/ports, the NFS server run on FreeBSD and work properly (No problem with NFS client on my laptop under FreeBSD). So, I can mount NFS directory without any problem. For a time I can write and read properly. But when I launch some commands using the NFS directory (like cvs or umount), the process hang. I can kill it, and the mounted NFS doesn't work. root 25157 0.0 1.3 2512 3436 p1- D 12:00AM0:00.06 cvs checkout -P 0 1 0 -5 0 nfs_fsy root 2099 0.0 0.0 26476 p0 D+12:27PM0:00.02 umount /usr/ports0 12769 0 -1 0 nfsrcvl I suppose NFS client is waiting for something, but I can't stop it. On debug messages he say Oct 31 00:53:58 solo /bsd: nfs server squat.philpep.org:/usr/OpenBSD/ports: not responding. But NFS client on my laptop still works, no problem with DNS, network is ok on the alix board. I've no errors on the server. And the mouted directory is squat.philpep.org:/usr/OpenBSD/ports on /usr/ports type nfs (v3, udp, timeo=100, retrans=101) This is always reproductible. How can I have more verbose output ? Thanks by advance.
pf: NAT, ALTQ and pflow at the same time
Hello!
My LAN (10.51.0.0/16) is behind OpenBSD router with pf.
vlan2 - external interface, vlan621 - internal.
In order to count traffic from Internet to LAN and vice versa with pflow
I need to use states on internal interface vlan621. But when states are enabled
then queues do not work. My current config of pf:
TRANSLATION RULES:
nat on vlan2 inet proto tcp from 10.51.109.16/29 to any - 193.200.84.226
nat on vlan2 inet proto tcp from 10.51.109.40/29 to any - 193.200.84.226
nat on vlan2 inet proto udp from 10.51.109.16/29 to any - 193.200.84.226
nat on vlan2 inet proto udp from 10.51.109.40/29 to any - 193.200.84.226
nat on vlan2 inet proto icmp from 10.51.109.16/29 to any - 193.200.84.226
nat on vlan2 inet proto icmp from 10.51.109.40/29 to any - 193.200.84.226
FILTER RULES:
block drop in all
pass in quick on vlan2 proto tcp from any to (vlan2) port = ssh flags S/SA keep
state (if-bound)
pass out quick on vlan2 all flags S/SA keep state (if-bound)
pass in quick on vlan2 all no state
pass in quick on vlan621 inet from 10.51.109.16/29 to any flags S/SA keep state
(if-bound, pflow)
pass out quick on vlan621 inet from any to 10.51.109.16/29 no state queue
to_Akim
pass in quick on vlan621 inet from 10.51.109.40/29 to any flags S/SA keep state
(if-bound, pflow)
pass out quick on vlan621 inet from any to 10.51.109.40/29 no state queue
to_Gonta
ALTQ:
queue root_em0 on em0 bandwidth 1Gb priority 0 {DEFQ, to_Customers}
queue DEFQ on em0 bandwidth 100Mb hfsc( default )
queue to_Customers on em0 bandwidth 10Mb {to_Akim, to_Gonta}
queue to_Akim on em0 bandwidth 512Kb hfsc( upperlimit 512Kb )
queue to_Gonta on em0 bandwidth 512Kb hfsc( upperlimit 512Kb )
With this configuration pflow works, but queues - do not.
Is there a way to get both pflow and queuing enabled on the same interface?
Thanks in advance.
--
MINO-RIPE
Source for LENOVO parts?
I have a Lenovo T60p (8744-J2U L3-CM199-07/07). I have been running OpenBSD on it since I purchased it (Summer 2007). The CPU fan is getting noisy and I'd like to replace it. The store where I purchased my laptop cannot order the replacement part. Can anyone suggest a supplier for this part? I live 200km west of Toronto, ON, Canada.
Re: machdep.allowaperture=1 setting is safer?
BTW, does anyone know if any other (X?) programs require '2', and in which cases? mplayer? I have been running mplayer, xine and openarena without any problems with value 1 for more than 6 months. Yours Srikant.
Re: Encrypting /home on OpenBSD Laptops
Maybe it's more usefull encrypted a file IN the /home partition and move the 'shit' there, then you create symlinks (ln -s) to the encrypted file and done. 2009/10/30 Brad Tilley b...@16systems.com: I wrote some notes on how I normally encrypt /home on OpenBSD laptops. I was hoping misc could read it and bash it around some. I'd like to know if I'm doing something wrong. No jokes about Beck's ass please :) http://16systems.com/openbsd_laptop_encryption.txt Thanks, Brad
Re: machdep.allowaperture=1 setting is safer?
Vadim Zhukov wrote: BTW, does anyone know if any other (X?) programs require '2', and in which cases? mplayer? No, it's related to physical memory access (..drivers) can access, if the X server starts then then the same programs will start.. X is the only thing that ever directly opens /dev/xf86. I use machdep.allowaperture=1 with nv(4) cards, but I notice visual corruption with r128(4).. but it's possible that I missed some xorg.conf setting. Matthieu Herrb wrote: see xf86(4). And yes the xf86-video-intel driver doesn't need the int10 emulation anymore so in this case '1' is enough to get it working '2' is needed by X.Org drivers that rely on the int10 emulation to get things setup through the bios of the card. I know this is unrelated, Matthieu.. but are you and Owain working on getting DRI/DRM working on other supported architectures? and fixing the other drivers (..ragedrm/mgadrm/machdrm/etc have been broken since 4.5). -Bryan.
Re: machdep.allowaperture=1 setting is safer?
On Sat, Oct 31, 2009 at 01:01:58PM +0300, Vadim Zhukov wrote: On 31 October 2009 c. 10:47:31 Matthieu Herrb wrote: '2' is needed by X.Org drivers that rely on the int10 emulation to get things setup through the bios of the card. And how can user easily detect that a driver rely on int10 emulation? Or no one should bother as the drivers will get fixed eventually? BTW, does anyone know if any other (X?) programs require '2', and in which cases? mplayer? It's not the X client, it's the driver. I'd guess that setting machdep.allowaperture incorrectly will cause X to fail very clearly at startup. Joachim
Re: Encrypting /home on OpenBSD Laptops
On Fri, Oct 30, 2009 at 07:57:08PM -0400, Brad Tilley wrote: I wrote some notes on how I normally encrypt /home on OpenBSD laptops. I was hoping misc could read it and bash it around some. I'd like to know if I'm doing something wrong. No jokes about Beck's ass please :) http://16systems.com/openbsd_laptop_encryption.txt Encrypting just /home is dangerous. Do you know where vi(1) keeps its backup files? Are you *sure* that's the only application that works like that? And that nothing ever uses /tmp? Realistically, / cannot be encrypted since you need some files to boot, and /usr can probably reasonably be kept unencrypted. Everything else - /home, /tmp, /var - needs encryption (or not, but in that case nothing does). You should also be careful to note that /root is not encrypted under this scheme. Joachim
Re: machdep.allowaperture=1 setting is safer?
On Sat, Oct 31, 2009 at 2:08 PM, Brynet bry...@gmail.com wrote: I know this is unrelated, Matthieu.. but are you and Owain working on getting DRI/DRM working on other supported architectures? and fixing the other drivers (..ragedrm/mgadrm/machdrm/etc have been broken since 4.5). It's on the TODO list, but no one is actively working on that. Volunteers are welcome, think that with all the work Owain did to clean up and integrate the dri drivers in /sys/dev/pci/drm, it's now a lot easier to study the working drivers in order to fix the non-working ones. -- Matthieu Herrb
Re: Encrypting /home on OpenBSD Laptops
On Sat, Oct 31, 2009 at 9:30 AM, Joachim Schipper joac...@joachimschipper.nl wrote: You should also be careful to note that /root is not encrypted under this scheme. The title says it all. Like most normal people, I keep data in /home. I don't care about meta data that might be in /tmp and I do not wish to encrypt /. This is not an effort to avoid law-enforcement or encrypt every bit on the disk, only to provide some privacy for the vast majority of my data should the laptop be lost or stolen and end-up in a pawn shop. Encrypting /home does that, nothing more. Brad
Re: Encrypting /home on OpenBSD Laptops
Brad Tilley wrote: I wrote some notes on how I normally encrypt /home on OpenBSD laptops. I was hoping misc could read it and bash it around some. I'd like to know if I'm doing something wrong. No jokes about Beck's ass please :) http://16systems.com/openbsd_laptop_encryption.txt Thanks, Brad don't bother encrypting just /home, do everything except the root partition. you can do this using softraid crypto as follows: - dump your existing partitions to another disk connected to the machine e.g. a usb drive - wipe the original disk - do a fresh install from a recent i386 or amd64 snapshot and break to shell instead of following the usual install option - follow the content of the softraid manpage to setup an encrypted disk, using fdisk and disklabel to prepare the disk yourself i.e. (assumes base disk name is sd0) fdisk -iy sd0, disklabel -E sd0, make a smallish 100-150 MB 4.4BSD partition for root and the rest of the disk set as a single partition of type RAID e.g. /dev/sd0a is root and /dev/sd0b is softraid, write disklabel, bioctl -c C -r 32768 -l /dev/sd0b softraid0, enter passphrase, and now you've got a second disk according to bsd.rd, sd1. not sure if you need to partition sd1 in the shell or in the installation script, you can figure it out - before rebooting make sure that your /etc/fstab lists the crypto partitions (everything except root) as being on sd1 - when you reboot, the boot process will 'fail' and dump you to shell since sd1 is not unlocked as part of the boot process - at a shell do the following to get your disk rollin: bioctl -c C -l /dev/sd0b softraid0, enter passphrase, issue 'fsck -fp exit' if you had a dirty shutdown otherwise just type exit - normal boot resumes and you've got your machine running with everything but root encrypted do note that i used tedu's suggestion of increasing the round count when making the crypto partition above. the steps listed above are almost complete but should be ***tested on a spare disk before doing this with a production system***. cheers, jake
Re: Source for LENOVO parts?
The same thing happened to me 2 months ago. Maybe this fan is not very reliable. Anyway, I bought mine online on the IBM France website. For Canada, it seems you have to contact the Toronto Parts Order Centre https://www-304.ibm.com/shop/americas/content/home/store_IBMPublicCanada/en_CA/parts.html Le samedi 31 octobre 2009 C 08:31 -0400, Frank Bax a C)crit : I have a Lenovo T60p (8744-J2U L3-CM199-07/07). I have been running OpenBSD on it since I purchased it (Summer 2007). The CPU fan is getting noisy and I'd like to replace it. The store where I purchased my laptop cannot order the replacement part. Can anyone suggest a supplier for this part? I live 200km west of Toronto, ON, Canada.
Re: Encrypting /home on OpenBSD Laptops
If you have enough memory you can avoid the /tmp problem by moving it into RAM: fstab: swap /tmp mfs rw,async,nodev,nosuid,-s=200 0 0 This will also speed up some things that write to /tmp. But keep in mind that in case of a crash the content is lost (if this is relevant for you). regards, Robert Joachim Schipper wrote: On Fri, Oct 30, 2009 at 07:57:08PM -0400, Brad Tilley wrote: I wrote some notes on how I normally encrypt /home on OpenBSD laptops. I was hoping misc could read it and bash it around some. I'd like to know if I'm doing something wrong. No jokes about Beck's ass please :) http://16systems.com/openbsd_laptop_encryption.txt Encrypting just /home is dangerous. Do you know where vi(1) keeps its backup files? Are you *sure* that's the only application that works like that? And that nothing ever uses /tmp? Realistically, / cannot be encrypted since you need some files to boot, and /usr can probably reasonably be kept unencrypted. Everything else - /home, /tmp, /var - needs encryption (or not, but in that case nothing does). You should also be careful to note that /root is not encrypted under this scheme. Joachim
Re: Encrypting /home on OpenBSD Laptops
* To Unmount, do this: - # unmount /home + # umount /home # vnconfig -v -u svnd0 /Markus Brad Tilley wrote: I wrote some notes on how I normally encrypt /home on OpenBSD laptops. I was hoping misc could read it and bash it around some. I'd like to know if I'm doing something wrong. No jokes about Beck's ass please :) http://16systems.com/openbsd_laptop_encryption.txt Thanks, Brad
What VM does OpenBSD run well under
I am planing on rebuilding my laptop shortly. I plan on putting Ubuntu 9.10 as the base OS, and I want to be able to run OpenBSD as a guest OS under one of the FM' choices. Preferably one of the free ones (eg not VMWare). What is the wisdom of the list on this? -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Re: Encrypting /home on OpenBSD Laptops
On Sat, Oct 31, 2009 at 10:00 AM, Jacob Yocom-Piatt j...@fixedpointgroup.com wrote: disk name is sd0) fdisk -iy sd0, disklabel -E sd0, make a smallish 100-150 MB 4.4BSD partition for root and the rest of the disk set as a single partition of type RAID e.g. /dev/sd0a is root and /dev/sd0b is softraid, write disklabel, bioctl -c C -r 32768 -l /dev/sd0b softraid0, enter passphrase, and now you've got a second disk according to bsd.rd, sd1. not Avoid using partition 'b' for anything but swap. Yeah, I'm basically superstitious, but it's best to not tempt fate by putting real data in the reserved for swap partition.
Re: What VM does OpenBSD run well under
I've been running it under virtualbox quite a while. Has trouble compiling a full release, but does well other than that, -B On Sat, Oct 31, 2009 at 8:12 AM, stan st...@panix.com wrote: I am planing on rebuilding my laptop shortly. I plan on putting Ubuntu 9.10 as the base OS, and I want to be able to run OpenBSD as a guest OS under one of the FM' choices. Preferably one of the free ones (eg not VMWare). What is the wisdom of the list on this? -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Re: Problems with 4.5 as a KVM guest
On Sat, Oct 31, 2009 at 09:42:58AM +0100, Michiel van Baak wrote: I tried to upgrade my 4.5 and got the same. Sorry, have no way around it for the moment. I reverted the vm back to it's previous working state. GENERIC has a few things enabled that play hob with current generation KVM and QEMU. Stock OpenBSD 4.5 will boot after install on Virtual Box. From there you can build a kernel with a custom config with those things deconfigured. Back in July I tracked down the relevant problem pieces, but have since forgotten what worked and what didn't. Config files and kernels are available at http://ftp.linux.org.uk/~pakrat/obsd45 At least one of the configs and kernels works with July 24th vintage KVM on Ubuntu Hardy with Ubuntu Intrepid kernel and libc. I'm fairly certain I posted about it here back then and on the KVM mailing lists back then. I found the ballpark for the config changes after READING the KVM mailing lists from around the time 4.5 was released. I have yet to be bored enough to repeat the excercise with OpenBSD 4.6. -- Chris Dukes
Re: What VM does OpenBSD run well under
On Sat, Oct 31, 2009 at 10:12:02AM -0500, stan wrote: I am planing on rebuilding my laptop shortly. I plan on putting Ubuntu 9.10 as the base OS, and I want to be able to run OpenBSD as a guest OS under one of the FM' choices. Preferably one of the free ones (eg not VMWare). What is the wisdom of the list on this? As memory serves I went with Virtual Box directly from Sun's website when i tracked down the bits to disable in GENERIC to get it to play nice under KVM. It works under KVM. I vaguely recall mpbios0 and acpmiadt0 need to be disabled. -- Chris Dukes
Re: What VM does OpenBSD run well under
It works under KVM. I vaguely recall mpbios0 and acpmiadt0 need to be disabled. Then it doesn't work. I've got this car, but the engine won't start. But it works fine, because if some friends help me I can push it down the road. We won't cripple OpenBSD just because the virtual machines out there are full of bugs. It should be a warning to you. How many of those bugs are holes? Your assumption is that none are. My assumption is that every single of them is some kind of hole.
pf n00b
I'm fresh off the boat from Debian. I love OpenBSD's attitude, and the
documentation is even pretty decipherable, but I'm still a little
confused by pf. I managed to build a trivial filter, but there are a
few things I don't understand.
I read somewhere (3 books, google, the website docs, and man) that a
longer rule takes longer to do its work. Why? I don't understand how
pf works -- I'd expect pfctl, while it's munging pf.conf, to make most
of the conditions into a big mask that could just with the IP
header and make a decision on the result. So specifying the proto and
both addresses and flags shouldn't make much difference in efficiency.
No?
pf.conf consists largely of anchors (to fork on protocol) and sub-
anchors below them to fork on service -- I'm trying to reduce the
count of rules seen by a packet to a minimum. But
pfctl -vs Anchors
gives this (in part):
/root:# pfctl -vs Anchors
TCP_IN
TCP_IN/POP3
TCP_IN/SMTP
TCP_IN/SSH
TCP_IN/TCP_IN
TCP_IN/TCP_IN/POP3
TCP_IN/TCP_IN/SMTP
TCP_IN/TCP_IN/SSH
Here's the TCP_IN anchor:
anchor TCP_IN/* in inet proto tcp from any port 1023 to $OUTSIDE
flags S/SA {
anchor SMTP/* inet proto tcp to port smtp {
block drop in quick from ASIA_BLK
block drop in quick from SMTP_BLK
pass in quick
}
anchor POP3/* inet proto tcp to port pop3 {
block drop in quick from ASIA_BLK
block drop in quick from POP_BLK
pass in quick
}
anchor SSH/* inet proto tcp to port ssh {
block drop in quick from ASIA_BLK
block drop in quick from SSH_BLK
pass in quick
}
pass in inet proto tcp to port rsync
}
Why does pfctl say there's a TCP_IN/TCP_IN?
Do there have to be /*s after all the anchor names?
Is it true that sub-anchors are 'evaluated' in alphabetical order as
opposed to the order in the file? If so, is there a reason for this?
Is the pf list from Christmas Island still viable? I tried twice to
subscribe and got bounced as spam both times.
And is there a way to get rid of an anchor without rebooting? When I
change spellings,
pfctl -s Anchors
shows the old ones still in there.
TIA...
--
Glenn English
g...@slsware.com
Re: pf n00b
On 1 November 2009 c. 00:00:41 ghe wrote: I'm fresh off the boat from Debian. I love OpenBSD's attitude, and the documentation is even pretty decipherable, but I'm still a little confused by pf. I managed to build a trivial filter, but there are a few things I don't understand. I read somewhere (3 books, google, the website docs, and man) that a longer rule takes longer to do its work. Why? I don't understand how pf works -- I'd expect pfctl, while it's munging pf.conf, to make most of the conditions into a big mask that could just with the IP header and make a decision on the result. So specifying the proto and both addresses and flags shouldn't make much difference in efficiency. No? Not mask, it's a number of if checks to be done. But you should not bother, it's fast enough, comparing to other things pf and network stack do. pf.conf consists largely of anchors (to fork on protocol) and sub- anchors below them to fork on service -- I'm trying to reduce the count of rules seen by a packet to a minimum. But pfctl -vs Anchors Bad idea. pf is not iptables. Read FAQ for examples, and start from scratch using tricks from those examples, not from iptables. Sorry, I wouldn't comment the next part of your message because you're moving in the wrong direction anyway. Why does pfctl say there's a TCP_IN/TCP_IN? Because you defined it, no? :) Do there have to be /*s after all the anchor names? No, you need it just to evaluate subanchors of your anchor. Is it true that sub-anchors are 'evaluated' in alphabetical order as opposed to the order in the file? If so, is there a reason for this? No. And is there a way to get rid of an anchor without rebooting? When I change spellings, pfctl -s Anchors shows the old ones still in there. Yes, use pfctl -f or pfctl -a anchorname -f depending on what you actually want to do. -- Best wishes, Vadim Zhukov A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: pf n00b
On 2009-10-31, ghe g...@slsware.com wrote: pf.conf consists largely of anchors (to fork on protocol) and sub- anchors below them to fork on service -- I'm trying to reduce the count of rules seen by a packet to a minimum. But no need for that, we have automatic skip steps, and a ruleset optimizer that re-orders where it makes sense. see the 3 articles on undeadly about pf for some fundamentals, starting here; http://undeadly.org/cgi?action=articlesid=20060927091645 (this is for an old version; since then the optimizer is enabled by default, pfctl -o isn't necessary).
Re: umask for remote host in sftp / sftp-server
Lars Nooden wrote: How can umask be set on the remote host for chrooted sftp users? You can set it on the server side with sftp-server's -u option but that's very new (post 4.6). You would have something like this in sshd_config: Subsystem sftp sftp-server -u 0022 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Re: What VM does OpenBSD run well under
On Sat, Oct 31, 2009 at 01:57:20PM -0600, Theo de Raadt wrote: It works under KVM. I vaguely recall mpbios0 and acpmiadt0 need to be disabled. Then it doesn't work. I've got this car, but the engine won't start. But it works fine, because if some friends help me I can push it down the road. We won't cripple OpenBSD just because the virtual machines out there are full of bugs. It should be a warning to you. How many of those bugs are holes? Your assumption is that none are. My assumption is that every single of them is some kind of hole. OpenBSD 4.4 works under KVM without modification. OpenBSD 4.5+ works if mpbios is disabled, more info here: http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04 I haven't tried 4.5+ under Ubuntu 9.10; perhaps the newer KVM or upstream QEMU has fixed the bugs that make 4.5+ not work out of the box. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st
Re: What VM does OpenBSD run well under
OpenBSD 4.5+ works if mpbios is disabled, more info here: http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04 OpenBSD 4.5 works on 99.9% of PCs out there with mpbios enabled, so KVM must have a really stupid bug.
Re: What VM does OpenBSD run well under
I've had decent luck with VirtualBox as of late, in previous versions VirtualBox would cause problems at install time bugging out when extracting packages. I've never had a problem with VMware though, but my experience is limited. I've been running it under ESXi 4.0 for a while and it's been very stable.
Re: pf n00b
On Sat, Oct 31, 2009 at 03:00:41PM -0600, ghe wrote:
I'm fresh off the boat from Debian. I love OpenBSD's attitude, and
the documentation is even pretty decipherable, but I'm still a
little confused by pf. I managed to build a trivial filter, but
there are a few things I don't understand.
I read somewhere (3 books, google, the website docs, and man) that a
longer rule takes longer to do its work.
I can't speak for the books, and I KNOW google is full of lies, but can
you point out specifically what parts of the website docs and man page
talks about this? It should be removed.
Why? I don't understand how pf works -- I'd expect pfctl, while it's
munging pf.conf, to make most of the conditions into a big mask that
could just with the IP header and make a decision on the result.
PF is designed to have a considerably more flexible and fine-grained
filtering mechanism, so what goes on is considerably more complicated
than just a bitwise against the header.
So specifying the proto and both addresses and flags shouldn't make
much difference in efficiency. No?
Actually, under many circumstances specifying the proto and addresses
will IMPROVE the performance of the ruleset evaluation even though it
makes the individual rule evaluation slower.
The number of rules evaluated makes a lot more difference than the
number of parameters evaluated per rule.
pf.conf consists largely of anchors (to fork on protocol) and sub-
anchors below them to fork on service -- I'm trying to reduce the
count of rules seen by a packet to a minimum. But
This approach is almost guaranteed to have the opposite effect.
My number one advice for people who want to optimize their rulesets for
performance is: DON'T.
Seriously.
Writing firewall rules is hard, anything more than a trivial ruleset is
easy to screw up and challenging to test. So the #1 goal for your
ruleset should be readability and maintainability. While you're at it,
put your ruleset under revision control, and figure out a good way to
test any ruleset changes that get made.
That being said, here are some things you can do while you're doing the
above which will help performance.
- stateful filtering (don't use 'no state')
- pfctl optimizer (don't use 'set ruleset-optimization none')
- use tables for lists of addresses
- use as few rules as possible to get the filtering you want
while keeping the ruleset readable.
Now, if you really, really need to optimize your ruleset for
performance, it's important to know that PF doesn't simply walk through
the rules as you've specified in your pf.conf when; pfctl optimizes the
rules as they are loaded into the kernel, and PF has a mechanism called
'skip steps' which will skip evaluation of rules if it's known in
advance that the rules cannot possibly match.
The skip steps attributes are the following:
* interface
* direction
* address family
* protocol
* source address
* source port
* destination address
* destination port
The best thing that you can actively do for ruleset performance is to
get out of the way of these mechanisms.
- Make use of the rule expansion in pf.conf (rules with items listed in
braces { }) rather than manually expanding them. The expansion is done
by pfctl in the skip steps order.
- Group your rules by the skip-steps parameters, in the order above.
(ie, all rules for em0 together; within that group, all the 'in' rules
together, within that, all ipv4 rules together...)
- For the above parameters, specify as much detail as possible without
adding more rules; increased detail will give skip-steps more to work
with.
- Make sparing use of barrier rule options, which prevent the ruleset
optimizer from reordering the ruleset efficiently.
* label
* prob
* state limits
* max_states
* max_src_nodes
* max_src_stats
* max_src_conn
* max_src_conn_rate
* anchor
- This means: Don't break the ruleset into anchors for performance
reasons unless you _really_ know what you're doing. If you DO, it's
probably best to break it up in skip-steps order (ie, by interface
first).
If you're STILL having performance issues after this, there are a few
more things you can do. Remember though:
Premature optimization is the root of all evil
-- Donald Knuth
- Write your ruleset with 'first match' ordering (quick) on
all/most rules, and use the 'profile' ruleset-optimization
- Filter only on one side of the firewall, using 'set skip' for the
interface on the other side.
- Group rules using optimizer breaks together; the optimizer
will only reorder or merge them if they are the same. (Roughly stated,
these are the 'actions' that a rule can perform).
* tag
* keep state
* queue
* routing (rt, route-to,
Re: What VM does OpenBSD run well under
On Sat, Oct 31, 2009 at 05:50:57PM -0600, Theo de Raadt wrote: OpenBSD 4.5+ works if mpbios is disabled, more info here: http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04 OpenBSD 4.5 works on 99.9% of PCs out there with mpbios enabled, so KVM must have a really stupid bug. Something about the mpbios implementation on OpenBSD does not seem right as disabling with 'bsd -c' does not have the same result as building a kernel with mpbios0 disabled in the config. That and your 99.9% comment lead me to believe there is a bug in OpenBSD. Given 1) Per mpbios.c ACPI and a useable MPBIOS appear to be mutually exclusive 2) New PCs are shipping with ACPI instead of APM 3) GENERIC with mpbios enabled breaks on 0.1% of PCs. I'm at a bit of a loss as to why mpbios is still enabled in GENERIC. My memory of the brief discussion on the KVM mailing list was that KVM/QEMU emulation of one of the instructions executed by going through the mpbios code was mishandled. If you'd like me to find the relevant thread and forward it on to the mpbios maintainer, I'll gladly do so. Now to pragmatic considerations. I understand and appreciate your mistrust of running OpenBSD under a virtual machine emulator. But there are folks like me that find it useful to be able to hold a dog and pony show for a network and cluster design on a laptop rather than an anvil case of laptops, switches, and routers. -- Chris Dukes
Re: What VM does OpenBSD run well under
On Sat, Oct 31, 2009 at 05:50:57PM -0600, Theo de Raadt wrote: OpenBSD 4.5+ works if mpbios is disabled, more info here: http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04 OpenBSD 4.5 works on 99.9% of PCs out there with mpbios enabled, so KVM must have a really stupid bug. Something about the mpbios implementation on OpenBSD does not seem Wait. We don't implement MPBIOS. It is a table provided by a machine. That machine is KVM. On all real machines machine, we don't crash. Get it? right as disabling with 'bsd -c' does not have the same result as building a kernel with mpbios0 disabled in the config. That and your 99.9% comment lead me to believe there is a bug in OpenBSD. Given 1) Per mpbios.c ACPI and a useable MPBIOS appear to be mutually exclusive That would be false. 2) New PCs are shipping with ACPI instead of APM What is your point? 3) GENERIC with mpbios enabled breaks on 0.1% of PCs. No, that is not true. The result we get with KVM does not happen on *any real machine*. I'm at a bit of a loss as to why mpbios is still enabled in GENERIC. To make you cry, obviously. There couldn't be *any other explanation* could there? My memory of the brief discussion on the KVM mailing list was that KVM/QEMU emulation of one of the instructions executed by going through the mpbios code was mishandled. If you'd like me to find the relevant thread and forward it on to the mpbios maintainer, I'll gladly do so. MPBIOS is a table given by the hardware. KVM is trying to act as if it is hardware, but compared to even QEMU, it sucks. Now to pragmatic considerations. I understand and appreciate your mistrust of running OpenBSD under a virtual machine emulator. But there are folks like me that find it useful to be able to hold a dog and pony show for a network and cluster design on a laptop rather than an anvil case of laptops, switches, and routers. That is not what is going on here.
Re: What VM does OpenBSD run well under
On Sat, Oct 31, 2009 at 11:29 PM, Chris Dukes pak...@pr.neotoma.org wrote: I'm at a bit of a loss as to why mpbios is still enabled in GENERIC. Because more machines work with mpbios that don't work without it than machines that work without it but not with it. My memory of the brief discussion on the KVM mailing list was that KVM/QEMU emulation of one of the instructions executed by going through the mpbios code was mishandled. If you'd like me to find the relevant thread and forward it on to the mpbios maintainer, I'll gladly do so. If the KVM emulation of one the instructions is mishandled, I don't understand how that is a bug in OpenBSD.
