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 paol...@gmail.com 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 pettijo...@hotmail.com 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.
Re: Packet Filter router i368 vs 64bit
On Thu, 27 Nov 2014 20:10:14 -0800 jungle Boogie jungleboog...@gmail.com wrote: Hi Brad, On 27 November 2014 at 19:51, Brad Smith b...@comstyle.com 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.
Confused about authpf real world usage
On Thu, 27 Nov 2014 17:09:02 +0100 Martin Hanson greencopperm...@yandex.com 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.
Multiple NICs vs multiple physical firewalls
On Sat, 22 Nov 2014 16:46:43 +0100 Martin Hanson greencopperm...@yandex.com 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 js.li...@gmail.com wrote: On Mon, Nov 10, 2014 at 8:30 AM, Scott Vanderbilt li...@datagenic.com 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 semarie-open...@latrappe.fr 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 vl...@bsdbg.net 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
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 jth...@astro.indiana.edu
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 ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT
SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0:
Re: strange behavior in disklabel partitioning of new disk
On Tue, 04 Nov 2014 00:53:38 -0500 Brian McCafferty br...@mccafferty.ca 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
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
jth...@astro.indiana.edu 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
