Re: x over ssh [SOLVED]
as long as you have an X server running somewhere (the server is what is attached to the display), you can run programs (clients) anywhere, local or remote. so yes, a headless server can run X programs that display elsewhere. see the faq, section 11. On Sun, 14 Dec 2014 10:55:16 +0100 Paolo Aglialoro wrote: > Does this also work when u do it from OpenBSD to a headless (just no video > card) OpenBSD server? Can I run X stuff on that remote box too? > > Il 14/dic/2014 05:46 "Edgar Pettijohn" ha scritto: > > > > On Dec 13, 2014, at 8:51 PM, Hugo Villeneuve wrote: > > > > > On Sat, Dec 13, 2014 at 07:12:07PM -0600, Edgar Pettijohn wrote: > > >> I can't seem to figure out how to startx over ssh. I seem to be > > >> getting closer, but not sure where the problem lays. I'm connecting > > >> to an OpenBSD 5.6 box from an iMac. It really isn't necessary but > > >> Its bugging me that I can't figure it out. > > >> > > >> $ ssh -X 192.168.1.5 -l root > > >> root@192.168.1.5's password: > > >> Last login: Sat Dec 13 18:17:13 2014 from 192.168.1.4 > > >> OpenBSD 5.6 (GENERIC) #0: Fri Dec 12 22:23:14 CST 2014 > > >> > > > > > > I'm not sure what you want to acheive. > > > > > > "startx" without arguments should only be run from the server console > > > directly. That is, startx run X which takes over the server video > > > card, keyboard and mouse. I will do nothing on the computer you > > > "ssh" from. > > > > > > When I want a "full" X session from a remote server to be displayed > > > locally. I use "Xnest", a special X server that is just a client > > > to another one. > > > > > > If you have XQuartz on your Mac, run something like: > > > > > > ssh -X hostname -l user "/usr/X11R6/bin/startx -- /usr/X11R6/bin/Xnest > :5 -once -geometry 1600x900" > > > > > > (Maybe I completly misunderstood what you meant.) > > > > > > > > > > You sir are a genius.
Confused about authpf real world usage
On Thu, 27 Nov 2014 17:09:02 +0100 Martin Hanson wrote: > Hi > > So I am looking into authpf and I am wondering about some real world > applications. > > I have a bunch of users, but I also have just a bunch of machines. > > The machines cannot login via SSH and should not try to do so (via some > script or otherwise). However, these machines needs access 24/7. then authpf may not be what you need. the purpose of authpf is to ensure that the person needing outside access has to authenticate first, and it needs ssh. > > So I was thinking about fixing rules to those machines before any > anchors for users, but I cannot see how this provides any security at > all - and bear with me if I am overlooking something. > > If say machine 192.168.0.2 and 192.168.0.3 needs unrestricted access to > the net, then wont it be as easy as "Joe" changing his machines IP > address to 192.168.0.2 to gain access without authentication? theoretically this is possible, but only if the original machine holding the ip was down. just as a nameserver converts to an ip, the ip is converted to a MAC-address, which is associated with the NIC. if you want you can permantly associate an ip with a mac, that way another machine cannot use that ip address, even if the rightful holder is down. see arp(8). > > And what about other kinds of access? Now I get a brand new box in that > needs a fresh installation of some Linux distribution that we install > over HTTP. This new box doesn't come with a SSH console and the install > disk doesn't provide a console with SSH during installation. this is not a problem, you can configure a gateway to allow any access you want. you can't use authpf for this however, but you could restrict the machine being updated to only use http and only to a particular address if you want. pf is VERY flexible. the pf firewall tutorial is here: http://home.nuug.no/~peter/pf/en/long-firewall.html > > Then I am beginning to see signs of "network segmentation" in my head, > but that kindda makes authpf more or less useless then - unless I need > to grant different people different access on the same segment I can > just segment the entire net. > > Anyway, I hope I make sense! :) > > How do you use authpf in real life? just like the man page says. that way you can know who is using the network as opposed to what (machine) is using it. > > Kind regards.
Re: Packet Filter router i368 vs 64bit
On Thu, 27 Nov 2014 20:10:14 -0800 jungle Boogie wrote: > Hi Brad, > On 27 November 2014 at 19:51, Brad Smith wrote: > > On 11/27/14 22:35, jungle Boogie wrote: > >> Anyone have any objections? I know the NICs are not intel so that will > >> probably get a strike against it, but I like the low power. > > > > > > Unless you guys give some sort of hints as to what these routers and / > > or firewalls are going to be used for just asking for hardware > > recommendations without such details is useless. What sort of throughput > > / packets per second do you forsee on the inside network? What is your > > target or expectation? If there is a WAN connection how fast is it? Are > > you lucky enough to have Gbit or is it only say a 50Mbps connection? > > Those types of details matter. > > > > > > I think the WAN on my home connection is 100Mbit. I'd essentially like > it to replace the cable company netgear router. > > Regarding PPS, I have no idea how I'd measure that. It would be > serving a home network with moderate network usage. I'd like basically > have a router that I can experiment with pf and openbsd without the > worry that the hardware is no good. > > > > > -- > > > > Thanks, > jb > > -- > --- > inum: 883510009027723 > sip: jungleboo...@sip2sip.info > xmpp: jungle-boo...@jit.si > you can just use old hardware for these purposes. from the man who literally wrote the book on pf (from pf tutorial via http://home.nuug.no/~peter/pf/en/long-firewall.html): I have not seen comparable tests performed recently [3.1 era], but in my own experience and that of others, the PF filtering overhead is pretty much negligible. As one data point, the machine which gateways between one of the networks where I've done a bit of work and the world is a Pentium III 450MHz with 384MB of RAM. When I've remembered to check, I've never seen the machine at less than 96 percent 'idle' according to top.
Multiple NICs vs multiple physical firewalls
On Sat, 22 Nov 2014 16:46:43 +0100 Martin Hanson wrote: > Hi all > > I have one gateway and several boxes serving some NFS, Samba and other stuff. > Then I have a public server for some gaming. > > I am thinking about two different setups, but I am in serious doubt as to > whether one actually has any real benefit over the other. > > The public server gets its own NIC on the firewall, whereas the other boxes > share another NIC (through a switch) for local stuff. > > My worries is if the public server gets hacked. > > Is it better to physically segment the network using two different boxes as > routers/firewalls, or is it better to simply use one router/firewall with 3 > NICs? > > Setup 1: > > Gateway --> firewall --> NIC1 --> public server > | > --> NIC2 --> LAN > > Setup 2: > > Gateway --> firewall1 --> public server > --> firewall2 --> LAN > > I am wondering about which of the two situations are "most secure". > > Maybe it really depends on how the firewall is setup, but what I want to > avoid is that if the public server gets hacked, that the attacker can gain > access to stuff on the LAN. > > Any comments on these different setups? > > Of course the ideal would properly be to get two separate Internet > connections, but that's really not an option in this case. > > Kind regards. > setup 1 should be fine, you can just block everything to the firewall from the public server. that way, the public server is compromised it cannot connect to anything. block in on $pub_server_if pass out on $pub_server_if this will allow all traffic initiated thru the firewall out (to the $pub_server), and replies back in, but any traffic initiated on that $if (from $pub_server) will be blocked. you can optionally log it as well: block in log on $pub_server_if which would give you a log of all traffic initiated from the public server, if and when it gets compromised. that would be closest to 'most secure'. if you want to allow the public server access to the outside, it gets more complicated. you may need to allow dns requests out for instance: pass in quick on $pub_server_if proto udp from $server_ip to any to port dns study pf faq/man well, and there is also a pf firewalling tutorial at http://home.nuug.no/~peter/pf/ in sum: block in log on $pub_server_if pass in quick on $pub_server_if proto udp from $server_ip to port 53 pass out on $pub_server_if should completely isolate the server except in response to outside requests and inside dns requests.
Re: Question about /etc/mail post 5.6 upgrade
On Tue, 11 Nov 2014 15:31:27 -0800 Joe S wrote: > On Mon, Nov 10, 2014 at 8:30 AM, Scott Vanderbilt > wrote: > > > > > > These changes came after 5.6 was RTM, and are reflected in -current as of > > 15 September or so. > > > > See http://www.openbsd.org/faq/current.html. > > > > Removing sendmail as outlined above will make things like 'make release' > break. I upgraded to 5.6 and decided to remove sendmail. I needed to add it > back because I couldn't make a release. > what error messages are you getting? i've been following -current for a while, and deleted sendmail when that page was updated, but have not had any problems (did 'make release' last night). my situation is not exactly the same as yours though, since i did a fresh install from a snapshot before following -current. just as an aside, i usually pipe the output thru 'tee' to save a copy for later checking eg if i get errors.
Re: CVS: cvs.openbsd.org: src
On Sun, 9 Nov 2014 10:09:49 +0100 =?utf-8?Q?S=C3=A9bastien?= Marie wrote: > On Sat, Nov 08, 2014 at 10:57:41PM +0200, Atanas Vladimirov wrote: > > On 24.10.2014 00:33, Robert Peichaer wrote: > > > > I'm following -current and decided to try autoinstall(8) from > > /auto_upgrade.conf when I moved to newer snapshot. > > I made a custom auto_upgrade.conf on my root [sd2a] partition but when I > > boot a newer bsd.rd, > > auto_upgrade.conf is not on the miniroot. I escaped to shell, mounted sd2a > > on /mnt and copied auto_upgrade.conf to miniroot. > > Then Autoupgrade completed as it should. > > The question is whether there are any easier steps to make auto_upgrade from > > local file, not by using dhcp/tftp/http? > > Thanks, > > Atanas > > The auto_upgrade.conf is searched in the ramdisk partition (which was > into bsd.rd). As thevoid@ wrote, you could rebuild a new bsd.rd image to > include it. > > Personnally, I extract the ramdisk image from bsd.rd, mount it, copy the > auto_upgrade.conf to it, and restore the ramdisk into bsd.rd. > > Here the "pseudo-script" I use: > > # build rdsetroot > ( cd /usr/src/distrib/common && cc -o /tmp/rdsetroot elf32.c elf64.c > elfrdsetroot.c ) > > # extract ramdisk from bsd.rd > /tmp/rdsetroot -x bsd.rd ramdisk.img > > # mount ramdisk > vnconfig vnd0 ramdisk.img > mount /dev/vnd0a /mnt > > # copy config file > cp auto_upgrade.conf /mnt/auto_upgrade.conf > > # umount ramdisk > umount /dev/vnd0a > vnconfig -u vnd0 > > # put modified ramdisk in bsd.rd > /tmp/rdsetroot bsd.rd ramdisk.img > > # cleanup > rm ramdisk.img > > And now, you could boot your modified bsd.rd. > -- > Sébastien Marie > i like this. for this particular purpose, this is definitely a better method.
Re: CVS: cvs.openbsd.org: src
On Sat, 08 Nov 2014 22:57:41 +0200 Atanas Vladimirov wrote:
> On 24.10.2014 00:33, Robert Peichaer wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: r...@cvs.openbsd.org2014/10/23 15:33:21
> >
> > Modified files:
> > distrib/miniroot: dot.profile install.sub
> > distrib/notes : m4.common
> > share/man/man8 : autoinstall.8
> >
> > Log message:
> > Extend autoinstall(8) feature:
> >
> > - Ask for responsefile location (url or local path) if dhcp discovery
> > fails for location or mode. If 'next-server' is found in dhcp lease
> > file, provide a default url http://next-server/install.conf.
> >
> > - Ask for installer mode if the specified response file name does not
> > match *install.conf or *upgrade.conf.
> >
> > - If present, use /auto_install.conf or /auto_upgrade.conf as response
> > file for unattended installation or upgrade.
> >
> > - Automatically start installer in unattended mode if either one of
> > these files is present when the system boots.
> >
> > - Document changes in manpage and installation notes.
> >
> > OK krw@ deraadt@
>
> I'm following -current and decided to try autoinstall(8) from
> /auto_upgrade.conf when I moved to newer snapshot.
> I made a custom auto_upgrade.conf on my root [sd2a] partition but when I
> boot a newer bsd.rd,
> auto_upgrade.conf is not on the miniroot. I escaped to shell, mounted
> sd2a on /mnt and copied auto_upgrade.conf to miniroot.
> Then Autoupgrade completed as it should.
> The question is whether there are any easier steps to make auto_upgrade
> from local file, not by using dhcp/tftp/http?
> Thanks,
> Atanas
>
you can make your own bsd.rd. this is a method i have used for custom
auto-installs for years (among other uses).
make sure to get the src{,sys}.tar.gz files for whatever snapshot you are
using.
# cp auto_upgrade.conf /usr/src/distrib/miniroot/
to '/usr/src/distrib/miniroot/list', add the line:
COPY${CURDIR}/auto_upgrade.conf auto_upgrade.conf
# cd /usr/src && make obj
# cd /usr/src/distrib/special/libstubs && make
# cd /usr/src/distrib/`arch -s`/ramdisk_cd && make
this should leave you with with a bsd.rd in obj/, just drop it in as a
replacement for the install one.
strange behavior in disklabel partitioning of new disk
i just noticed an obvious stupid mistake of mine, the 'dd' should go before
the 'fdisk' as well (for the same reason as 'disklabel').
On Tue, 04 Nov 2014 07:04:23 -0500 thev...@openmailbox.org wrote:
> yes, you are zeroing the whole disklabel, which is located in the openbsd area
> starting at 32k (or 64 sectors). make sure you do the 'disklabel' AFTER 'dd'.
>
> if you do a 'dd if=/dev/sd0c bs=512 skip=64 count=2 | strings' and you should
> see the disk's model number (after the disklabel has been configured of
> course).
>
> i have a script with a procedure that works consistently, which does the
> following:
>
this:
> fdisk -iy $DISK
>
> #clear old softraid data
> dd if=/dev/zero of=/dev/r${DISK}c bs=1m count=1
should be this:
#clear old softraid data
dd if=/dev/zero of=/dev/r${DISK}c bs=1m count=1
fdisk -iy $DISK
> #clear the disklabel and add raid partition
> echo "z\na\n\n\n\nRAID\nw\nq\n\n" | disklabel -E $DISK >/dev/null
>
> #create softraid device
> bioctl -c C -l /dev/${DISK}a softraid0
>
> dd if=/dev/zero of=/dev/r${SRDISK}c bs=1m count=1
> fdisk -iy $SRDISK
> disklabel -E $SRDISK
> newfs ...
>
> where $DISK is your disk (sd0 in your case), and $SRDISK is the softraid dev
> created by bioctl (maybe sd1, watch bioctl's output)
>
> On Mon, 3 Nov 2014 22:33:45 -0500 Jonathan Thornburg
> wrote:
> > I'm trying to set up 5.6/amd64 on a new-from-the-factory 750GB disk
> > which I've just had installed in a Thinkpad T60. (This Thinkpad had
> > previously been running 5.5/amd64 using an older/smaller disk, with
> > no problems).
> >
> > I want to try having the entire new disk secured with softraid crypto.
> > So, I booted the Thinkpad (with the new disk installed) from my 5.6/amd64
> > CD (dmesg below) and dropped into the shell. The dmesg shows that the
> > bsd.rd kernel detected the new disk as sd0.
> >
> > To try to set up the new disk, I first did
> > # fdisk -i sd0
> > to set up the MBR partitions, then
> > # disklabel -E sd0
> > to add a single 'a' partition of type 'RAID' containing all the space
> > after the first 64 sectors (reserved as per "Disklabel tricks and tips"
> > in section 14.3 of the OpenBSD FAQ). So far so good:
> >
> > # fdisk sd0
> > Disk: sd0 geometry: 91201/255/63 [1465149168 Sectors]
> > Offset: 0 Signature: 0xAA55
> > Starting Ending LBA Info:
> > #: id C H S - C H S [ start:size ]
> > ---
> > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> >
> > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> >
> > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> >
> > *3: A6 0 1 2 - 91200 254 63 [ 64: 1465144001 ] OpenBSD
> >
> > # disklabel sd0
> > # /dev/rsd0c:
> > type: SCSI
> > disk: SCSI disk
> > label: WDC WD7500BPKX-2
> > duid: 407d46caba526d90
> > flags:
> > bytes/sector: 512
> > sectors/track: 63
> > tracks/cylinder: 255
> > sectors/cylinder: 16065
> > cylinders: 91201
> > total sectors: 1465149168
> > boundstart: 64
> > boundend: 1465144065
> > drivedata: 0
> >
> > 16 partitions:
> > #size offset fstype [fsize bsize cpg]
> > a: 1465144001 64RAID
> > c: 14651491680 unused
> > #
> >
> > Next I tried to follow the instructions in section 14.21 of the FAQ
> > and zero the first megabyte of the new partition:
> >
> > # dd if=/dev/zero bs=1m count=1 of=/dev/rsd0a
> >
> > Now the "strange behavior": Checking the output of fdisk and disklabel
> > again as a sanity check, I find that the fdisk output is unchanged (as it
> > should be!), but disklabel now shows that the newly-created 'a' partition
> > has vanished, and the duid has been zeroed:
> >
> > # disklabel sd0
> > # /dev/rsd0c:
> > type: SCSI
> > disk: SCSI disk
> > label: WDC WD7500BPKX-2
> > duid:
> > flags:
> > bytes/sector: 512
> > sectors/track: 63
> > tracks/cylinder: 255
> > sectors/cylinder: 16065
> > cylinders: 91201
> > total sectors: 1465149168
> > boundstart: 64
> > boundend: 1465144065
> > drivedata: 0
> >
> > 16 partitions:
> > #size offset fstype [fsize bsize cpg]
> > c: 14651491680 unused
> > #
> >
> > It's as if the 'a' partition I created (which started at offset 64) was
> > actually overlapping the disklabel metadata!
> >
> > One other data point: I also saw the same behavior ('a' partition gone,
> > duid zeroed) when I repeated the same commands but with the (recreated)
> > 'a' partition having the default '4.2BSD' fstype instead of 'RAID'.
> >
> > Can anyone clue me in as to what's I'm doing wrong?
> >
> > I thought I understood disk partitioning (and I'm fully aware that
> > overlapping partitions
Re: strange behavior in disklabel partitioning of new disk
On Tue, 04 Nov 2014 00:53:38 -0500 Brian McCafferty wrote: > On 11/03/14 22:33, Jonathan Thornburg wrote: > > I'm trying to set up 5.6/amd64 on a new-from-the-factory 750GB disk > > which I've just had installed in a Thinkpad T60. (This Thinkpad had > > previously been running 5.5/amd64 using an older/smaller disk, with > > no problems). > > > > I want to try having the entire new disk secured with softraid crypto. > > So, I booted the Thinkpad (with the new disk installed) from my 5.6/amd64 > > CD (dmesg below) and dropped into the shell. The dmesg shows that the > > bsd.rd kernel detected the new disk as sd0. > > > > I do fdisk -iy sd0 there should be another 'dd' here, just in case a previous softraid was configured. bioctl will find old data, and try to get the old passphrase instead of asking for a new one. > then create the RAID on sd0 > then MAKEDEV sd1 > then run #bioctl -c C -l /dev/sd0a softraid0 > then zero 1m of rsd1c > then install to sd1
strange behavior in disklabel partitioning of new disk
yes, you are zeroing the whole disklabel, which is located in the openbsd area
starting at 32k (or 64 sectors). make sure you do the 'disklabel' AFTER 'dd'.
if you do a 'dd if=/dev/sd0c bs=512 skip=64 count=2 | strings' and you should
see the disk's model number (after the disklabel has been configured of course).
i have a script with a procedure that works consistently, which does the
following:
fdisk -iy $DISK
#clear old softraid data
dd if=/dev/zero of=/dev/r${DISK}c bs=1m count=1
#clear the disklabel and add raid partition
echo "z\na\n\n\n\nRAID\nw\nq\n\n" | disklabel -E $DISK >/dev/null
#create softraid device
bioctl -c C -l /dev/${DISK}a softraid0
dd if=/dev/zero of=/dev/r${SRDISK}c bs=1m count=1
fdisk -iy $SRDISK
disklabel -E $SRDISK
newfs ...
where $DISK is your disk (sd0 in your case), and $SRDISK is the softraid dev
created by bioctl (maybe sd1, watch bioctl's output)
On Mon, 3 Nov 2014 22:33:45 -0500 Jonathan Thornburg
wrote:
> I'm trying to set up 5.6/amd64 on a new-from-the-factory 750GB disk
> which I've just had installed in a Thinkpad T60. (This Thinkpad had
> previously been running 5.5/amd64 using an older/smaller disk, with
> no problems).
>
> I want to try having the entire new disk secured with softraid crypto.
> So, I booted the Thinkpad (with the new disk installed) from my 5.6/amd64
> CD (dmesg below) and dropped into the shell. The dmesg shows that the
> bsd.rd kernel detected the new disk as sd0.
>
> To try to set up the new disk, I first did
> # fdisk -i sd0
> to set up the MBR partitions, then
> # disklabel -E sd0
> to add a single 'a' partition of type 'RAID' containing all the space
> after the first 64 sectors (reserved as per "Disklabel tricks and tips"
> in section 14.3 of the OpenBSD FAQ). So far so good:
>
> # fdisk sd0
> Disk: sd0 geometry: 91201/255/63 [1465149168 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start:size ]
> ---
> 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> *3: A6 0 1 2 - 91200 254 63 [ 64: 1465144001 ] OpenBSD
>
> # disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: WDC WD7500BPKX-2
> duid: 407d46caba526d90
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 91201
> total sectors: 1465149168
> boundstart: 64
> boundend: 1465144065
> drivedata: 0
>
> 16 partitions:
> #size offset fstype [fsize bsize cpg]
> a: 1465144001 64RAID
> c: 14651491680 unused
> #
>
> Next I tried to follow the instructions in section 14.21 of the FAQ
> and zero the first megabyte of the new partition:
>
> # dd if=/dev/zero bs=1m count=1 of=/dev/rsd0a
>
> Now the "strange behavior": Checking the output of fdisk and disklabel
> again as a sanity check, I find that the fdisk output is unchanged (as it
> should be!), but disklabel now shows that the newly-created 'a' partition
> has vanished, and the duid has been zeroed:
>
> # disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: WDC WD7500BPKX-2
> duid:
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 91201
> total sectors: 1465149168
> boundstart: 64
> boundend: 1465144065
> drivedata: 0
>
> 16 partitions:
> #size offset fstype [fsize bsize cpg]
> c: 14651491680 unused
> #
>
> It's as if the 'a' partition I created (which started at offset 64) was
> actually overlapping the disklabel metadata!
>
> One other data point: I also saw the same behavior ('a' partition gone,
> duid zeroed) when I repeated the same commands but with the (recreated)
> 'a' partition having the default '4.2BSD' fstype instead of 'RAID'.
>
> Can anyone clue me in as to what's I'm doing wrong?
>
> I thought I understood disk partitioning (and I'm fully aware that
> overlapping partitions are doubleplusungood!), but I have the feeling
> I'm missing something obvious here
>
> --- begin dmesg ---
> OpenBSD 5.6 (RAMDISK_CD) #303: Fri Aug 8 00:25:26 MDT 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 3203203072 (3054MB)
> avail mem = 3112607744 (2968MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
> bios0: vendor LENOVO version "7IET23WW (1.04 )" date 12/27/2006
> bios0: LENOVO 87424GU
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT E
