how to know uuid
linux has blkid . in openbsd , what is its substitute ?
Re: cu connection trap "crash"
On Sat, Aug 8, 2015 at 3:36 PM, Dan Becker wrote: >> On Saturday, August 8, 2015, Dan Becker wrote: >>> >>> When connecting to a serial port with a usb to serial adapter. Unplugging >>> the usb connection without closing the session causes my system to drop >>> to ddb. ... > $ cat /var/run/dmesg.boot > OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I'm 98% certain that this was fixed in April or so, and thus fixed in -current and will be fixed in 5.8. If not, well, it's now too late to debug and fix it before 5.8 is frozen. So, you should upgrade to 5.8 soon after it comes out and verify whether this is resolved there. If not, report it again then, with fresh dmesg and backtrace, so that it can be addressed when there's time in the 5.9 cycle... Philip Guenther
Re: Repartitioning
Also, another question: this system keeps nothing in the user's home directories past a few dot files. /home is using less than 1m of space. Would it be safe from a security/reliability standpoint to just move the home folders directly into / ?
Re: Repartitioning
You've stated you have a 10GB disk, and that this is 4.9. The disklabel(8) man page at 4.9 described the automatic layout at that time: Yeah, that's what we have. You have stated that /usr/src and /usr/obj are unused, /var is full, and /usr/local (used for packages and some infrastructure components) is nearly empty. Yep. The disklabel(8) tool is used to delete and create partitions. So part of the reason I started this thread is that I want to be clear since OpenBSD has two different kinds of "partitions". For what I'm doing, on an i386 platform, I don't need to mess with fdisk at all... Is that correct? would allow you to grow /usr with growfs(8). growfs is like other partition expanders in that can only expand "forward" and not "backward", right? As in, I couldn't nuke src and obj and then use growfs to expand home into that space. Assuming that's right, I'm probably going to make a new /var partition rather than expand an existing one. so you may need to do some backup / restore to external media, Honestly, there's so much free unused space that I can directly copy everything to it's final destination right off the bat. The best practice for moving of FFS filesystems is through the use of dump(8)/restore(8). I'm not sure that's what I want to be doing in my case. Especially when collapsing the /usr/* stuff down into just /usr, a simple cp or tar would be better, no? FAQ 14 may also be helpful, as it lays out the basics of disk management. Yeah I read all that first, but it doesn't answer a lot of specifics.
Re: Repartitioning
2015/08/08 22:25 "Quartz" : >> >> Maybe I missed it, but if you supply the output of disklabel and df, >> it would be easier to give advice. > > > The machine isn't in front of me right now, but the partition setup was using the 'wizard' defaults. In other words: /, /tmp, /var, /usr, /usr/X11R6, /usr/local, /usr/src, /usr/obj, and /home, in that order. All the usr's (except x11) and home are set for a couple gigs each but only using a few hundred megs collectively. /var is a few hundred megs and close to full. > (IIRC) disklabel -h sd0 > mylabel.txt df -h >> mylabel.txt cat mylabel.txt | mail -s Repartitioning misc@openbsd.org or something like that. (Maybe wd0 instead of sd0.) It really is easier to communicate if we can talk about specifics. > Nuking src and obj will free up a lot, but I think it would make more sense to collapse all the usr stuff into just /usr, move home into where var currently is, and move var into the new space. > So, use newfs. Once you have deleted your unused partitions, how you cut the space it opens up is entirely up to you. I have often found myself doing something like this. Reread the manual pages , just to get your creative juices flowing. du -S /var/* will tell you which subdirectories of /var are good candidates for moving off /var . Virtualizing the problem child is also good, if you don't need to test the old stuff on some actual piece of hardware, but playing with your partitions is good practice, too. -- Joel Rees
Re: Repartitioning
On Sat, Aug 08, 2015 at 08:24:53PM -0400, Quartz wrote: > >One man already asked you for disklabel output. > > That WAS the disklabel output (minus sizes and offsets). When I next get a > chance to ssh into it from somewhere else I'll copy the actual output, but > the exact blocks shouldn't really matter for all this. You've stated you have a 10GB disk, and that this is 4.9. The disklabel(8) man page at 4.9 described the automatic layout at that time: Disks > 6.5 Gigabytes /5% of disk. 80M - 1G swap 5% of disk. 80M - 2x max physical memory /tmp 8% of disk. 120M - 4G /var13% of disk. 80M - 2x size of crash dump /usr 2% of disk. 600M - 2G /usr/X11R6 3% of disk. 512M - 1G /usr/local 5% of disk. 2G - 6G /usr/src 3% of disk. 1G - 2G /usr/obj 3% of disk. 1G - 2G /home 53% of disk. 1G - 300G You have stated that /usr/src and /usr/obj are unused, /var is full, and /usr/local (used for packages and some infrastructure components) is nearly empty. If you boot in single-user mode, you can manipulate any partition other than the root partition. For that, you must use the RAMDISK kernel. The disklabel(8) tool is used to delete and create partitions. With it, you can delete the partitions for /usr/src and /usr/obj, as they are unused. That will give you a 2GB empty area which you may repurpose. For example, you could create a new partition in that space, and move /var there. You could continue to move, mix and match, and restructure as needed. For example, you could migrate the contents of /usr/local into /usr, freeing an additional 0.5 GB, and you could do the same with /usr/X11R6 ... assuming there is room in /usr. Eliminating all partitions between /usr/X11R6 and /usr/obj, inclusively, would allow you to grow /usr with growfs(8). However, you can't grow it until the other partitions have been removed, so you may need to do some backup / restore to external media, or perhaps use freespace in /home as a temporary location to store dump(8) output, if it has capacity. The newfs(8) tool is used to format partitions. The best practice for moving of FFS filesystems is through the use of dump(8)/restore(8). FAQ 14 may also be helpful, as it lays out the basics of disk management.
Re: Repartitioning
... in that order. This order could be not identical with the harddisk order. If I'm not mistaken, watching install operation, I think the / partition is the first followed by /home. Somebody correct me if I'm wrong. I've looked at the layout on this machine a dozen times. Cross reference with man disklabel if you don't believe me. One man already asked you for disklabel output. That WAS the disklabel output (minus sizes and offsets). When I next get a chance to ssh into it from somewhere else I'll copy the actual output, but the exact blocks shouldn't really matter for all this.
Re: cu connection trap "crash"
On Sat, Aug 8, 2015 at 2:12 PM, Philip Guenther wrote: > On Saturday, August 8, 2015, Dan Becker wrote: > >> When connecting to a serial port with a usb to serial adapter. Unplugging >> the usb connection without closing the session causes my system to drop to >> ddb. >> >> Can someone else try to verify this ? >> >> No flags, simply 'cu /dev/cuaU0 ' >> >> http://1drv.ms/1Dy9w4J >> >> ddb screenie ^ > > > dmesg? > > inline... disk wasn't mounted properly because this is probably the 4th time I repeated the process to make sure I could :) $ cat /var/run/dmesg.boot OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4160286720 (3967MB) avail mem = 4045619200 (3858MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfb4c0 (43 entries) bios0: vendor FUJITSU // Phoenix Technologies Ltd. version "Version 1.15" date 07/05/2011 bios0: FUJITSU LIFEBOOK S751 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT HPET APIC MCFG ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices UAR1(S3) HDEF(S4) PCE0(S4) PCE3(S3) GLAN(S4) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.69 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.34 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.34 MHz cpu2: 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2494.34 MHz cpu3: 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,A ES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 1 (PCE0) acpiprt3 at acpi0: bus 10 (PCE2) acpiprt4 at acpi0: bus 11 (PCE3) acpiprt5 at acpi0: bus 12 (PCE7) acpiec0 at acpi0 acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpicpu2 at acpi0: C2, C1, PSS acpicpu3 at acpi0: C2, C1, PSS acpiac0 at acpi0: AC unit online acpibat0 at acpi0: CMB1 model "CP483691-01" serial 02A-Z110813001293Z type LION oem "Fujitsu" acpibat1 at acpi0: CMB2 not present acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: LCD_ cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2501, 2500, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1366x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured puc0 at pci0 dev 22 function 3 "Intel 6 Series KT" rev 0x04: ports: 1 com com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address b0:99:28:cb:b6:d3 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 2
Re: cu connection trap "crash"
On Sat, Aug 8, 2015 at 2:12 PM, Philip Guenther wrote: > On Saturday, August 8, 2015, Dan Becker wrote: > >> When connecting to a serial port with a usb to serial adapter. Unplugging >> the usb connection without closing the session causes my system to drop to >> ddb. >> >> Can someone else try to verify this ? >> >> No flags, simply 'cu /dev/cuaU0 ' >> >> http://1drv.ms/1Dy9w4J >> >> ddb screenie ^ > > > dmesg? > > Attachment -- --Dan [demime 1.01d removed an attachment of type application/octet-stream which had a name of dmesg.boot]
Re: cu connection trap "crash"
On Saturday, August 8, 2015, Dan Becker wrote: > When connecting to a serial port with a usb to serial adapter. Unplugging > the usb connection without closing the session causes my system to drop to > ddb. > > Can someone else try to verify this ? > > No flags, simply 'cu /dev/cuaU0 ' > > http://1drv.ms/1Dy9w4J > > ddb screenie ^ dmesg?
Re: Repartitioning
> ... in that order. This order could be not identical with the harddisk order. If I'm not mistaken, watching install operation, I think the / partition is the first followed by /home. Somebody correct me if I'm wrong. One man already asked you for disklabel output.
Re: rdomain with BGP dynamic route
On Thu, Jul 30, 2015 at 11:26:56AM -0400, XU, YANG (YANG) wrote:
> Adam,
>
> Your comments and links are very helpful, they made some concepts clear
> for me. Many thanks!
>
> What I need essentially is VRF function which converts IPv4 prefix to
> VPNv4 prefix dynamically. I hope experts can help on this. After
> spending so much time on searching for the answer, sending beer is an
> easier thing to do. Just give me a working example, and beer will be on
> the way :)
Hmm. To do this you need to run multiple bgpds one doing the VPNv4
handling and then a bgpd instance per client (running that specific
rdomain). For those client bgpd you need to add some extra config to make
it all work:
# change fib priority so that bgpd does not filter those routes
fib-priority 36
# change location of bgpctl socket
socket "/var/run/bgpd.customer1.sock"
Then I think it is the easiest to start those client bgpd with
route -T 3 exec /usr/sbin/bgpd
This will run bgpd in rdomain 3. You still need an mpe(4) interface in
rdomain 3 so that the primary bgpd exports the routes (plus you will need
some ldpd and MPLS config as described in the presentation you mentioned).
It may be possible to use:
rde rib "customer-1" rtable 3
and some filter magic to run all in a single bgpd but I think that is a
lot more trouble than having different processes running.
Originally the idea was that the PE <-> CE route exachange would be done
via OSPF. This is why you need multiple processes for this setup.
--
:wq Claudio
>
> -Original Message-
> From: Adam Thompson [mailto:athom...@athompso.net]
> Sent: Tuesday, July 28, 2015 8:59 PM
> To: XU, YANG (YANG)
> Cc: misc@openbsd.org
> Subject: Re: rdomain with BGP dynamic route
>
> I see what you mean.
>
> This, I think, is close to what you're looking for, but I'm not 100% certain
> of how to accomplish exactly what you want:
>
>nexthop qualify via bgp
>listen on A.B.C.D ## vrf member address of, say, em1
>rtable 2 ## put vrf interface into rdomain 2 via ifconfig?
>rdomain 2 {
> rd 123:456
> depend on em1
>}
>neighbor VPNCLIENT1 {
> depend on em1
>}
>
> ...I don't know how to avoid running a separate instance of bgpd(8) per VRF,
> however.
>
> Given that OpenBSD has, apparently, a working MPLS + LDP implementation, this
> is obviously yet another case where the manual pages contain enough
> information
>
> Based on jeker's MPLS paper back at EuroBSDCon 2011, it may be the case that
> BGP + VRF really only works work mpe(4).
>
> Ah! I found someone else's documentation that explains it... you do still
> need to use rdomain0, but you MUST tag the routes. rdomain0 contains
> everything, including the [possibly overlapping] routes, but with prefixes to
> keep them separate.
>
> See http://firstyear.id.au/entry/21. Also see jeker's explanation (perhaps
> dated) here:
> http://openbsd-archive.7691.n7.nabble.com/Using-RDomain-setup-with-pf-4-and-bgpd-8-td42066.html.
>
> (Also check out http://lmgtfy.com/?q=openbsd+bgp+vrf. Admittedly, the fourth
> or fifth result _is_ this thread :-/.)
>
> Failing that, as I can't tell for certain if it does what you want, wait for
> Claudio, Henning, or whoever else is working on it now to figure out how to
> make it work better! I hear sending them beer sometimes helps...
>
> -Adam
>
>
>
>
> On 07/24/2015 08:07 PM, XU, YANG (YANG) wrote:
> > Adam,
> >
> > I really appreciate your reply. I read bgpd.conf and see rdomain can only
> > define network as explicit, static or connected. In my case, I need to
> > import dynamic prefix from BGP session. Right now all prefix learned from
> > BGP goes to rdomain 0. I want to put prefix learned from BGP into the
> > rdomain I specify.
> >
> > Thanks,
> > -Yang
> >
> > From: Adam Thompson [athom...@athompso.net]
> > Sent: 24 July 2015 20:33
> > To: XU, YANG (YANG)
> > Subject: Re: rdomain with BGP dynamic route
> >
> > On 2015-07-24 06:47 AM, XU, YANG (YANG) wrote:
> >> Let me describe it in another way. Can I create a new rdomain as a VRF and
> >> use the rdomain to import/export customer's prefix through BGP?
> >>
> >> I will greatly appreciate it if you can provide any information. I have
> >> seen some information online, but prefix is either from static
> >> configuration or connected network. In my case, I need to support dynamic
> >> routes from BGP in VRF.
> > Short answer: yes.
> >
> > See man bgpd.conf(5):
> >
> > ROUTING DOMAIN CONFIGURATION
> > bgpd(8) supports the setup and distribution of Virtual Private Networks.
> > It is possible to import and export prefixes between routing domains.
> > Each routing domain is specified by an rdomain section, which allows
> > properties to be set specifically for that rdomain:
> > rdomain 1 {
> > descr "a rdomain"
> > rd 65002:1
> > import-target rt 65002:42
> > export-target rt 65002:42
> > network 192.168.
cu connection trap "crash"
When connecting to a serial port with a usb to serial adapter. Unplugging the usb connection without closing the session causes my system to drop to ddb. Can someone else try to verify this ? No flags, simply 'cu /dev/cuaU0 ' http://1drv.ms/1Dy9w4J ddb screenie ^ -- --Dan
Re: SNMP on 5.7/5.8
sorry for top post. I believe I had the problem with both base and netsnmpd versions. On 06/08/15 00:33, Steven Surdock wrote: Thanks Stuart. It is also my understanding that the base snmpd suffers the same issue. http://marc.info/?l=openbsd-misc&m=143143933919367&w=2 I will try the debug shortly. -Steve S. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Stuart Henderson Sent: Wednesday, August 5, 2015 5:58 AM To: misc@openbsd.org Subject: Re: SNMP on 5.7/5.8 On 2015-08-04, Steven Surdock wrote: The broken SNMP on i386/5.7 is preventing me from upgrading. I tried i386/5.8 but I'm still seeing net-snmpd crash with the following error. NET-SNMP version 5.7.3 Error expanding HCInReceives to 64bits in ipSystemStatsTable.ipv4 Error expanding HCInDelivers to 64bits in ipSystemStatsTable.ipv4 Error expanding HCOutRequests to 64bits in ipSystemStatsTable.ipv4 Oh, I wasn't aware of this, if a port is broken on some arch please let the maintainer know rather than hope they notice a report on misc@... Can you get output with debugging enabled for "c64"? Should be something like snmpd -Dc64 -f -Le Do you particularly need something from Net-SNMP or could you use snmpd from base instead? If it does what you need, the latter is always preferable. Is amd64 the new i386? yes. Would my energy be best spent migrating my default install to amd64? Thanks. that's up to you to decide :)
Re: Repartitioning
Maybe I missed it, but if you supply the output of disklabel and df, it would be easier to give advice. The machine isn't in front of me right now, but the partition setup was using the 'wizard' defaults. In other words: /, /tmp, /var, /usr, /usr/X11R6, /usr/local, /usr/src, /usr/obj, and /home, in that order. All the usr's (except x11) and home are set for a couple gigs each but only using a few hundred megs collectively. /var is a few hundred megs and close to full. Nuking src and obj will free up a lot, but I think it would make more sense to collapse all the usr stuff into just /usr, move home into where var currently is, and move var into the new space.
Re: Current USB Wifi status
it is actually not worth buying a new standalone access point unless you can install specifically OpenBSD on it, and temporary reuse of an old access point is sub-optimal now matter what you (re)flash on it, most firmwares including third party are vulnerable and suffer from the same reliability and hardware limitations. There's a difference between a wifi *access point* and a wifi *router*. You can't install much of anything on an access point, it's basically just a bridge. They only have one ethernet port on the back and like maybe a couple megs of ram if that, enough to handle basic password/encryption and not much else. They have about the same reliability issues as an unmanaged ethernet switch (ie; not a lot). As for routers, depending on what you have, it's not too hard to reflash them into what is basically a wap. The crummy software is the source of 99% of their problems, but if you replace that with a simple bridge firmware they clear right up. I've never seen even the shittiest of linksys units fail because of actual hardware issues. As far as hardware limitations go, you're not going to be getting any more bandwidth out of a g/n/ac/whatever pci card vs the same class standalone device. The processor of the wap or flashed router won't be managing any states or anything, so there's not much of a difference there. Personally I wouldn't recommend buying a wifi router to turn it into a wap, but that's because it's a waste of money. Repurposing an old one is fine, as is buying a new wap. I've seen plenty of people do this and these things have run flawlessly for years.
Re: Current USB Wifi status
> It might be worth buying/reusing a standalone access point (perhaps > reflashing a linksys router or something) and connecting via ethernet > cable. That way you have more flexibility in choosing locations: ie, the > OpenBSD router can be somewhere that's convenient for interfacing with > your ISP's equipment, and the wap can be somewhere with good reception. > 'course, then you have two boxes to deal with, so it's a trade off. Another comment contradicting the above recommendation (nothing personal), it is actually not worth buying a new standalone access point unless you can install specifically OpenBSD on it, and temporary reuse of an old access point is sub-optimal now matter what you (re)flash on it, most firmwares including third party are vulnerable and suffer from the same reliability and hardware limitations. With the right cable (proper impedance and connectors on both ends, many shops provide various length conveniently) you can place your antenna (sector panel for indoor use is better in corners) some distance away from the (mini)PCI(e) device in your router, and still benefit from OpenBSD without relying on low quality (old) standalone access points (which often contain a very outdated and quite frequently exploitable version of Linux with a web interface on top). As previously said, the wireless device in the OpenBSD is your best chance of reliably functional setup (and the chance to learn this with OpenBSD instead of relying on a crippled external device, one more thing to worry about battery backed operation / POE (power over Ethernet)).
Re: Repartitioning
On 2015-08-07 Fri 10:33 AM |, Quartz wrote: > > Is there a good way to use the same disk? Again, the > issue is not that the disk is full, but that's it half empty and split up in > a way that we can't really use the space. > 1) Decide what partition layout & sizes you want (du, df, mount, etc...) http://www.openbsd.org/faq/faq4.html#Partitioning 2) Install 5.7's ramdisk kernel as /bsd.rd.57 3) on another box (BSD, Mac, Linux, Solaris, whatever...), setup inbound ssh key access for operator, & an operator writable cache large enough to hold disk dumps. e.g: /var/cache/puffy chflags nodump /var/cache/puffy 4) Shut down (practically) *everything*, leaving just init, gettys (& maybe sshd) running. 5) unmount everything possible, not /, nor /var 6) dump(8) what you want to save over ssh to another machine, e.g: [operator@puffy:~]$ dump -0anu -f - -h 0 /dev/rwd0f | gzip | \ ssh operator@another-box dd of=/var/cache/puffy/_home.dump.gz 7) TEST your dumps are restore(8) able, preferably on an OpenBSD box. Maybe there's space in /tmp for testing on the original box. 8) Reboot & boot /bsd.rd.57 9) *INSTALL* 5.7 with the manual partition layout you chose in (1) 10) Restore your dumps. 11) Get used to 5.7 & adapt your stuff to suit. 12) Celebrate by rock climbing/loch rowing/Highland Games hill running.. -- Innovation is hard to schedule. -- Dan Fylstra
Re: smtpd.conf.5 relay tls | verify
On sze, aug 05, 2015 at 06:49:42 +, David Dahlberg wrote: > Am Mittwoch, den 05.08.2015, 00:31 +0100 schrieb Jason McIntyre: > > > if this were the case, i'd say we want: > > [tls [verify]] > > Hmm, I think I have heard this proposal before ;-) > https://marc.info/?l=openbsd-misc&m=140196108217209 > > > but the doc currently says: > > > > Note that the tls and verify options are mutually exclusive > and > > should only be used in private networks as they will prevent > > proper relaying on the Internet. > > - Note that the tls and verify options are mutually exclusive > and > + Note that the tls and tls verify options > Got it! How about this: Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving revision 1.126 diff -u -p -p -u -r1.126 smtpd.conf.5 --- smtpd.conf.54 Jun 2015 14:23:00 - 1.126 +++ smtpd.conf.58 Aug 2015 08:06:19 - @@ -311,7 +311,7 @@ This parameter may use conversion specif .Op Ic hostname Ar name .Op Ic hostnames No < Ns Ar names Ns > .Op Ic pki Ar pkiname -.Op Ic tls | verify +.Op Ic tls Op verify .Ek .Xc .Pp @@ -389,19 +389,17 @@ is used instead. If .Ic tls is specified, OpenSMTPD will refuse to relay unless the remote host provides -STARTTLS. -.Pp -If +STARTTLS. If .Ic verify -is specified, OpenSMTPD will refuse to relay unless the remote host provides -STARTTLS and the certificate it presented has been verified. +is also specified, OpenSMTPD will also try to verify the certificate of the +host and refuses to relay if it is invalid. .Pp Note that the .Ic tls and -.Ic verify -options are mutually exclusive and should only be used in private networks -as they will prevent proper relaying on the Internet. +.Ic tls verify +options should only be used in private networks as they will prevent proper +relaying on the Internet. .It Xo .Ic relay via .Ar host -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Repartitioning
On August 8, 2015 2:13:02 AM GMT+02:00, Quartz wrote: >> How about taking some directory that is currently under /var >(depending >> on what you're doing with the machine, maybe log or www or mysql or >> something?) and moving the contents to /usr/obj or /usr/src (or if >> they're together on disk, remove /usr/obj and /usr/src and create a >> new partition covering the space that was used by both)? (Then change >> the mountpoint in /etc/fstab). If that gives you enough capacity, >> that might be easier than some big shuffle-around. > >That's kinda half-assing it for us, as that would still leave like >three >partitions around that are 95% empty consuming over a third of the >disk. >If I'm going to be redoing things, I might as well do it all at once. Maybe I missed it, but if you supply the output of disklabel and df, it would be easier to give advice. /Alexander
quem cant ping 8.8.8.8
Hi all .
i follow http://brycv.com/blog/2013/notes-on-openbsd-in-qemu-on-openbsd/
openbsd(rental server):vio0 157.7.208.141 internet
and
qemu-run.sh
export ETHER=vether0
export BRIDGE=bridge0
qemu-system-i386 first-image.img -m 512 \
-net nic,model=ne2k_pci -net tap
then
Ok from qemu ,ping 192.168.54.1
Ok from qemu ,ping 157.7.208.141
Ok from openbsd , ping 192.168.54.100
OK from openbsd , ping 157.7.208.1 (rental server's dhcpd server ? )
but
Fail from qemu , ping 8.8.8.8
Fail from qemu ping 157.7.208.1 (rental server's dhcpd server ? )
perhaps pf.conf of openbsd has defects .
---
tcp_services="{ 22, 25, 80, 143, 465, 587 }"
ext_if="vio0" <---openbsd's NIC
int_if="vether0"
pass in quick on $int_ifall
pass out quick on $int_ifall
pass out quick on $ext_if all
block in on $ext_if all
pass out on $ext_if all
pass in quick on $ext_if proto tcp from any to any port $tcp_services \
flags S/SA keep state
match out on $ext_if inet proto tcp from 192.168.54.10 to any nat-to
($ext_if)
match out on $ext_if inet proto tcp from ($int_if:network) to any
nat-to ($ext_if:0)
and
/etc/hostname.bridge0
add vether0
add tun0
up
i dream rdr port 49152(mediatomb) to 192.168.54.100(qemu)
---
regards
