Re: dhcpd(8) support for option domain-search
On Tue, Dec 24, 2013 at 8:22 AM, Kenneth R Westerback wrote: > On Mon, Dec 23, 2013 at 12:03:13AM -0700, Darren Spruell wrote: >> Wanted to verify my understanding that the included dhcpd(8) in base >> does not currently support the domain-search option: >> >> """ >> option domain-search domain-list; The domain-search option specifies a >> 'search list' of Domain Names to be used by the client to locate >> not-fully-qualified domain names. The difference between this option >> and historic use of the domain-name option for the same ends is that >> this option is encoded in RFC1035 compressed labels on the wire. For >> example: >> >> option domain-search "example.com", "sales.example.com", >> "eng.example.com"; >> """ >> >> dhcpd.conf(5) and dhcp-options(5) don't mention the option. > > option 119 (domain search, specified in rfc 3397) is not supported > in the base version of dhcpd. > > One *could* provide it with the syntax > > option-119 nn:nn:nn:nn:nn... > > where you provide the appropriate hex digits to specify the contents > of the option. Not a nice solution. :-) > > >> >> I can currently override the search domains on clients, and it seems >> like it might be supported in isc-dhcp-server package. Anything likely >> to make it into base? Simply a matter of patch not having been >> submitted, or anything deeper than that? > > Nothing deeper than that, as far as I know. Is option 119 in wide use as > far as you know? "As far as I know" for me doesn't extend very far at all. I can cite a few corporate environments where a list of search domains are given out because in typical disorganized hellhole fashion they want clients to resolve hosts in their several disjointed domains that have been cobbled together over the decades of poorly done mergers and acquisitions and technology upgrades. So I've seen it frequently in this regard. -- Darren Spruell phatbuck...@gmail.com
Re: Suspend/Resume and USB filesystems
On Fri, Jan 03, 2014 at 12:13:05AM -0500, Ted Unangst wrote: > On Fri, Jan 03, 2014 at 09:17, Helg Bredow wrote: > > I've been running OpenBSD 5.4 off a USB stick and couldn't get > > suspend/resume to work on either of my laptops. I thought maybe it was a > > driver issue but I've now installed the latest snapshot to the internal > > HDD and suspend/resume seems to be working fine. However, suspend causes a > > detach of the whole ugen to umass stack to detach so any mounted USB > > filesytems end up in an unclean state. This is probably what was causing > > it to fail when booting off USB. > > > > Is there anything that I need to configure in order to prevent this from > > happening? > > I don't think there's anything you can do. That's how the kernel does > things (detach usb, reattach). > > We could: > 1. postpone the device detach until after resume, and then only detach > devices which are actually missing. I'm not sure how much madness this > would involve. > 2. postpone forced filesystem unmount until after resume to see if the > disk comes back. I'm fairly certain this will involve a lot of madness. > This is not likely going to be fixed in any near timeframe. It's just too much headache. -ml
Re: Suspend/Resume and USB filesystems
On Fri, Jan 03, 2014 at 09:17, Helg Bredow wrote: > I've been running OpenBSD 5.4 off a USB stick and couldn't get > suspend/resume to work on either of my laptops. I thought maybe it was a > driver issue but I've now installed the latest snapshot to the internal > HDD and suspend/resume seems to be working fine. However, suspend causes a > detach of the whole ugen to umass stack to detach so any mounted USB > filesytems end up in an unclean state. This is probably what was causing > it to fail when booting off USB. > > Is there anything that I need to configure in order to prevent this from > happening? I don't think there's anything you can do. That's how the kernel does things (detach usb, reattach). We could: 1. postpone the device detach until after resume, and then only detach devices which are actually missing. I'm not sure how much madness this would involve. 2. postpone forced filesystem unmount until after resume to see if the disk comes back. I'm fairly certain this will involve a lot of madness.
Suspend/Resume and USB filesystems
I've been running OpenBSD 5.4 off a USB stick and couldn't get suspend/resume to work on either of my laptops. I thought maybe it was a driver issue but I've now installed the latest snapshot to the internal HDD and suspend/resume seems to be working fine. However, suspend causes a detach of the whole ugen to umass stack to detach so any mounted USB filesytems end up in an unclean state. This is probably what was causing it to fail when booting off USB. Is there anything that I need to configure in order to prevent this from happening? Thanks, helg
Re: Is Ext2 stable enough for normal use?
On Thu, Jan 2, 2014 at 8:27 PM, Chris Cappuccio wrote: > Evan Root [cellarr...@gmail.com] wrote: >> Just so you all know, >> This thread makes me want to try out Ext on Openbsd reeeaalll bad. > > It receives virtually no effort, and its performance sucks. Although, > linux ext2fs is very fast because they skip a level of integrity (perhaps > like mounting ffs with async) It is exactly like ffs/async, but with a very smart fsck. I think Ted T'so has been tweaking that thing for years. I've used ext2 for a very long time, even after ext3 appeared (don't much care for the journaling idea) and I've never lost a filesystem or even a file due to a crash. Yes, I know that it's theoretically possible that fsck won't be able to puth Humpty back together again, but it hasn't happened to me. I think part of it is the reliability of Linux -- crashes are extremely rare -- and I have my desktop systems on UPSes. So fsck has gotten few opportunities to fail.
Re: Is Ext2 stable enough for normal use?
Evan Root [cellarr...@gmail.com] wrote: > Just so you all know, > This thread makes me want to try out Ext on Openbsd reeeaalll bad. It receives virtually no effort, and its performance sucks. Although, linux ext2fs is very fast because they skip a level of integrity (perhaps like mounting ffs with async)
Re: Migrate to SSD
Stuart Henderson [s...@spacehopper.org] wrote: > > > Also, are there any /etc/fstab options recommended for SSDs? > > No need to fiddle, the defaults are fine. Perhaps a 'noatime' for SSD paritions if you want to keep more blocks clean for longer period of time.
Re: Migrate to SSD
Check out softdep as a fstab parameter. It is equally useful for regular spinning disks but it seems like you may not know about Soft updates. Evan Root, CCNA On Thu, Jan 2, 2014 at 8:27 AM, Jan Stary wrote: > On Jan 02 09:41:14, laurence.rochf...@gmail.com wrote: > > Hello, > > > > I want to migrate my current OpenBSD 5.4 installation to an SSD, which is > > slightly larger than my present rotational drive. > > > > What are people's suggestions for doing this? I was thinking of DDing and > > increasing the size of /home and /usr/local, but surely there's a better > > way? > > Unless your installation is very specific and there is something > precious beside /home and /etc/, just do a dump, install, restore. > > > Also, are there any /etc/fstab options recommended for SSDs? > > None which you wouldn't use for a classical disk as well.
Re: dmassage - openbsd 5.4 build failure
Riccardo, How much memory does the Omni 800 have right now? Evan Root, CCNA On Wed, Jan 1, 2014 at 6:46 PM, Theo de Raadt wrote: > >On Wed, Jan 1, 2014, at 06:17 PM, Theo de Raadt wrote: > >> I think dmassage being unmaintained for 12 years, and this issue just > >> coming up now, probably says a lot about that "type" of person. It's > >> a type of person who can't fix dmassage, and then, sends us a mail. > >> Sorry, but it's the truth. > > > >Very little, if anything, has changed in either the kernel configuration > >procedure or the format of a kernel's dmesg in the last 12 years. So > >this is more a case of "if it ain't broke, don't fix it." > > So glad to have the expert speak.
Re: NSA spy catalog (was: Re: apologies for the noise (interesting article)!)
2014/1/1 Erling Westenvik : > Anyway: When can we expect OpenBSD support for these devices? When devs detect them. Best Martin
Re: Is Ext2 stable enough for normal use?
On Thu, Jan 2, 2014 at 3:17 PM, wrote: > On 1/2/14, Geoff Steckel wrote: >> In return, of course, that Linux wouldn't mount an OpenBSD FFS. > > I used to have /home shared between OpenBSD and Linux a couple of > years ago when I was migrating. It was FFS for the reason discussed in > this thread. The version of OpenBSD was 5.0. I do not remember the > Linux kernel version but it looks very unlikely to me that they > dropped support for FFS. >From the mount man-page on an up-to-date Arch Linux system: Mount options for ufs ufstype=value UFS is a filesystem widely used in different operating systems. The problem are differences among implementations. Features of some implementations are undocumented, so its hard to recognize the type of ufs automatically. That's why the user must specify the type of ufs by mount option. Pos‐ sible values are: oldOld format of ufs, this is the default, read only. (Don't forget to give the -r option.) 44bsd For filesystems created by a BSD-like system (NetBSD,FreeBSD,OpenBSD). ufs2 Used in FreeBSD 5.x supported as read-write. 5xbsd Synonym for ufs2. sunFor filesystems created by SunOS or Solaris on Sparc. sunx86 For filesystems created by Solaris on x86. hp For filesystems created by HP-UX, read-only. nextstep For filesystems created by NeXTStep (on NeXT station) (currently read only). nextstep-cd For NextStep CDROMs (block_size == 2048), read-only. openstep For filesystems created by OpenStep (currently read only). The same filesystem type is also used by Mac OS X.
Re: Is Ext2 stable enough for normal use?
On 1/2/14, Geoff Steckel wrote: > In return, of course, that Linux wouldn't mount an OpenBSD FFS. I used to have /home shared between OpenBSD and Linux a couple of years ago when I was migrating. It was FFS for the reason discussed in this thread. The version of OpenBSD was 5.0. I do not remember the Linux kernel version but it looks very unlikely to me that they dropped support for FFS.
Re: Is Ext2 stable enough for normal use?
On 01/02/2014 02:25 PM, Evan Root wrote: > Just so you all know, > This thread makes me want to try out Ext on Openbsd reeeaalll bad. I might > just be able to provide real answers about how it works here in a couple > weeks. > > > > Evan Root, CCNA > > > > On Sat, Dec 21, 2013 at 1:13 AM, Maurice McCarthy > wrote: > >> On Thu, Dec 19, 2013 at 05:04:32AM -0600 or thereabouts, Shawn K. Quinn >> wrote: >>> I know for a fact that on GNU/Linux, NTFS performance is terrible, >>> especially on larger files. True story: once I tried backing up >>> something as a large .zip file to NTFS on a GNU/Linux system. The ETA >>> would start off saying something reasonable like "3 hours" then, three >>> hours later, it would be "about 8 hours" and it would keep going up from >>> there. >>> >> Shawn Quinn, I take it all back. The performance on ntfs in Ubuntu 13.04 >> is atrocious with large files. >> >> The tar archive of video that I mentioned before had _not finished after >> 5:01 hours but took another 5 hours to complete. >> >> So to verify I tried a plain copy command between two internal hardisks. >> After the first 7G transfer had decreased to under 200K per sec. My home PC >> has 8G of RAM. >> >> Regards >> Maurice Last time I tried to read an ext3 (with journal disabled) IIRC it would mount but no other operation worked. That was 5.2 or so. FS was written by Linux 3.2. In return, of course, that Linux wouldn't mount an OpenBSD FFS. Geoff Steckel
Re: Transparent proxy with Squid on OpenBSD 5.4
Hello,
First I have only one line in my pf.conf and it is:
pass in log on $int_if inet proto tcp from any \
to port { 80, 8080 } divert-to 127.0.0.1 port 3128
Second my squid.conf has only one line and it is:
http_port 127.0.0.1:3128 intercept
In your config files you are redirecting to port 3128
and you are intercepting at port 3129.
On Thu, Jan 2, 2014 at 7:55 PM, Romain FABBRI - Alien Consulting <
romain.fab...@alienconsulting.net> wrote:
> Hi,
>
> Im trying to do a transparent webfiltering bridge with squid.
> Ive used the packages for 5.4 which are squid-3.3.8 and squidGuard-1.4p6
>
> Squid is working fine when the browser uses the vether0 administration
> interface of the bridge.
> I mean sites are cached and squidGuard is filtering according to my tests
> rules.
>
> But its not working when using the bridge as a transparent proxy (without
> specifying a proxy server).
> If someony could give me some advice that would be really helpfull.
>
> Here is my /etc/pf.conf
>
> # Macros & Tables
> ext_if="bge0"
> int_if="bge1"
>
> # Options
> set skip on lo
> set skip on {pfsync}
> set reassemble yes no-df
>
> # Redirect www to our transparent squid proxy
> pass in quick log on $ext_if inet proto tcp to port 80 divert-to 127.0.0.1
> port 3128
> pass out quick from 127.0.0.1 divert-reply
>
> # Allow SSH
> pass quick inet proto tcp from any to 192.168.200.253 port ssh
>
> # Allow mail
> pass out quick proto tcp from $int_if to any port { 25, 143, 993, 995 }
> keep
> state
>
> # Allow Ping/Traceroute/DNS
> pass quick inet proto udp from any to any port domain
> pass quick inet proto tcp from any to any port domain flags S/SA synproxy
> state
> pass quick inet proto icmp all icmp-type { echoreq, unreach } keep state
>
> Ive tried almost every tutorial on the net but I had no luck with any of
> them using OpenBSD 5.4 and Squid 3.3.8
> So Im posting to know if anybody has done this kind of configuration
> successfully.
>
> Happy New Year
> Romain
>
>
>
> In /etc/squid/squid.conf I have configured ports like that :
>
> http_port 3128
> http_port 127.0.0.1:3129 intercept
Re: Is Ext2 stable enough for normal use?
Just so you all know, This thread makes me want to try out Ext on Openbsd reeeaalll bad. I might just be able to provide real answers about how it works here in a couple weeks. Evan Root, CCNA On Sat, Dec 21, 2013 at 1:13 AM, Maurice McCarthy wrote: > On Thu, Dec 19, 2013 at 05:04:32AM -0600 or thereabouts, Shawn K. Quinn > wrote: > > > > I know for a fact that on GNU/Linux, NTFS performance is terrible, > > especially on larger files. True story: once I tried backing up > > something as a large .zip file to NTFS on a GNU/Linux system. The ETA > > would start off saying something reasonable like "3 hours" then, three > > hours later, it would be "about 8 hours" and it would keep going up from > > there. > > > > Shawn Quinn, I take it all back. The performance on ntfs in Ubuntu 13.04 > is atrocious with large files. > > The tar archive of video that I mentioned before had _not finished after > 5:01 hours but took another 5 hours to complete. > > So to verify I tried a plain copy command between two internal hardisks. > After the first 7G transfer had decreased to under 200K per sec. My home PC > has 8G of RAM. > > Regards > Maurice
Transparent proxy with Squid on OpenBSD 5.4
Hi,
Im trying to do a transparent webfiltering bridge with squid.
Ive used the packages for 5.4 which are squid-3.3.8 and squidGuard-1.4p6
Squid is working fine when the browser uses the vether0 administration
interface of the bridge.
I mean sites are cached and squidGuard is filtering according to my tests
rules.
But its not working when using the bridge as a transparent proxy (without
specifying a proxy server).
If someony could give me some advice that would be really helpfull.
Here is my /etc/pf.conf
# Macros & Tables
ext_if="bge0"
int_if="bge1"
# Options
set skip on lo
set skip on {pfsync}
set reassemble yes no-df
# Redirect www to our transparent squid proxy
pass in quick log on $ext_if inet proto tcp to port 80 divert-to 127.0.0.1
port 3128
pass out quick from 127.0.0.1 divert-reply
# Allow SSH
pass quick inet proto tcp from any to 192.168.200.253 port ssh
# Allow mail
pass out quick proto tcp from $int_if to any port { 25, 143, 993, 995 } keep
state
# Allow Ping/Traceroute/DNS
pass quick inet proto udp from any to any port domain
pass quick inet proto tcp from any to any port domain flags S/SA synproxy
state
pass quick inet proto icmp all icmp-type { echoreq, unreach } keep state
Ive tried almost every tutorial on the net but I had no luck with any of
them using OpenBSD 5.4 and Squid 3.3.8
So Im posting to know if anybody has done this kind of configuration
successfully.
Happy New Year
Romain
In /etc/squid/squid.conf I have configured ports like that :
http_port 3128
http_port 127.0.0.1:3129 intercept
Re: Migrate to SSD
On Jan 02 09:41:14, laurence.rochf...@gmail.com wrote: > Hello, > > I want to migrate my current OpenBSD 5.4 installation to an SSD, which is > slightly larger than my present rotational drive. > > What are people's suggestions for doing this? I was thinking of DDing and > increasing the size of /home and /usr/local, but surely there's a better > way? Unless your installation is very specific and there is something precious beside /home and /etc/, just do a dump, install, restore. > Also, are there any /etc/fstab options recommended for SSDs? None which you wouldn't use for a classical disk as well.
Re: Migrate to SSD
On 2014-01-02 06:54, Gregory Edigarov wrote: but dump and restore on per filesystem basis would suffice There's one additional step, which is to use installboot(8) or disklabel(8) -B to install bootblocks.
Re: Migrate to SSD
On 01/02/2014 11:24 AM, Stuart Henderson wrote: On 2014-01-02, Laurence Rochfort wrote: Hello, I want to migrate my current OpenBSD 5.4 installation to an SSD, which is slightly larger than my present rotational drive. What are people's suggestions for doing this? I was thinking of DDing and increasing the size of /home and /usr/local, but surely there's a better way? When moving to a different disk, I usually just do a basic install of the same OS version (and backup/restore software if not using something in base) on the new disk with appropriate partition sizes, then restore from backups. dd is the wrong tool for this job. Even if you didn't want to change partition sizes I think dd would be the wrong tool. but dump and restore on per filesystem basis would suffice Also, are there any /etc/fstab options recommended for SSDs? No need to fiddle, the defaults are fine. -- With best regards, Gregory Edigarov
Re: Migrate to SSD
On 2014-01-02, Laurence Rochfort wrote: > Hello, > > I want to migrate my current OpenBSD 5.4 installation to an SSD, which is > slightly larger than my present rotational drive. > > What are people's suggestions for doing this? I was thinking of DDing and > increasing the size of /home and /usr/local, but surely there's a better > way? When moving to a different disk, I usually just do a basic install of the same OS version (and backup/restore software if not using something in base) on the new disk with appropriate partition sizes, then restore from backups. dd is the wrong tool for this job. Even if you didn't want to change partition sizes I think dd would be the wrong tool. > Also, are there any /etc/fstab options recommended for SSDs? No need to fiddle, the defaults are fine.
Migrate to SSD
Hello, I want to migrate my current OpenBSD 5.4 installation to an SSD, which is slightly larger than my present rotational drive. What are people's suggestions for doing this? I was thinking of DDing and increasing the size of /home and /usr/local, but surely there's a better way? Also, are there any /etc/fstab options recommended for SSDs? Many thanks, Laurence.
