Re: Memory alignment

2017-01-28 Thread Damian McGuckin

On Sat, 28 Jan 2017, Kyoung Jae Seo wrote:


Maybe posix_memalign(3) is API you are looking for.


No. This allocates memory.

I already have the buffer. I am trying to use space within it.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer



Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-28 Thread Jiri B
On Sat, Jan 28, 2017 at 12:17:40AM +0100, Sven-Volker Nowarra wrote:
> I am netbooting many systems, and last recently stepped on the issue, that I
> had an amd64 and an i386 client in the same network. I wanted to boot them
> into a "full" OpenBSD (not ramdisk kernel). That is not possible with the
> default installation, cause pxeboot can not distinguish between these
> Intel/AMD systems. DHCP server can distinguish by MAC address, but then when
> pxeboot is loaded, the kernel is per default "bsd". This must clash either
> with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry.
> So I went through some older mailing list entries, adapted them, and updated
> my meanwhile extensive netboot document. I updated this into a PDF, covering
> many, many details (now ~50 pages). Wanted to give something back to the
> community. The PDF is currently located here:
> http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf
> 

Thanks, interesting document.

Isn't better to use rewrite/file remapping instead of hacking pxeboot?
If an i386 machine would request /etc/boot.conf via tftp you could rewrite
it to (based on fact you know that that machine is i386 - during provisioning)
/etc/i386/boot.conf. For the client I suppose it would still think it gets
/etc/boot.conf.

j.



Re: Migrate Mailserver from sendmail/Curier/LDAP to OpenSMTP/Dovecot/LDAP

2017-01-28 Thread Craig Skinner
Hi Markus,

On 2017-01-27 Fri 12:24 PM |, Markus Rosjat wrote:
> I dont like the idea of one single virtual user handling all the traffic to
> the maildirectories.

Me neither.

Here, all users have proper shell accounts & SSH access, for mutt, etc.

Stop Dovecot, unmount /var/mail (where mail stays), dump(1). No SQL "spool".

There is no LDAP nor SQL, it is all simple stuff;-

*) The MTA delivers via LMTP to Dovecot - which sieves mail.
   (Thunderbird & other mail clients have a sieve plugin.)

*) Users IMAP/POP/SMTP auth via an individual passwd file,
   which they change via a script (which calls pwqcheck(1) in ports).
   /etc/passwd is _NOT_ used for mail authentication.
   (MTA SMTP submission port auth relaying is validated by Dovecot too.)

No webmail; everybody is expected to have their own IMAP/POP/SSH device.

$ doveconf -n
# 2.2.24 (a82c823): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.14 (099a97c)
# OS: OpenBSD 6.0 i386  ffs
auth_mechanisms = cram-md5 apop
auth_username_format = %Ln
first_valid_uid = 1000
listen = *
mail_location = maildir:/var/mail/%u
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate 
mime foreverypart extracttext
mbox_write_locks = fcntl
mmap_disable = yes
namespace inbox {
  inbox = yes
  location = 
  mailbox Archive {
auto = subscribe
special_use = \Archive
  }
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox Junk {
auto = subscribe
special_use = \Junk
  }
  mailbox Sent {
auto = subscribe
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Templates {
auto = subscribe
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix = 
  separator = /
  type = private
}
passdb {
  args = /var/dovecot/auth.d/%u/passwd.CRAM-MD5
  driver = passwd-file
}
passdb {
  args = /var/dovecot/auth.d/%u/passwd.CLEAR
  driver = passwd-file
  skip = authenticated
}
plugin {
  sieve = file:/var/mail/%u/sieve/;active=active.sieve
}
protocols = imap pop3 lmtp sieve
service auth {
  unix_listener /var/spool/postfix/private/dovecot-auth {
group = _postfix
mode = 0660
user = _postfix
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = _postfix
mode = 0660
user = _postfix
  }
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
}
ssl = no
userdb {
  args = blocking=no
  driver = passwd
  result_failure = return-fail
}
protocol lmtp {
  mail_plugins = " sieve"
  postmaster_address = postmaster
}


In the future I hope to be able to deploy OpenSMTPd,
when the filtering & other work has stabilised.

Cheers,
-- 
Craig Skinner | http://linkd.in/yGqkv7



tftpd rewrite example

2017-01-28 Thread Jiri B
Hi,

has anybody written some tftpd rewrite daemon/script which could
be shared as example?

j.



mprotect W^X violation and JDK

2017-01-28 Thread Currell Berry
Every time I start or stop a java program, I see something similar to
the following logged in /var/log/messages 

Jan 28 02:15:46 wtestvm3 /bsd: java(37284): mprotect W^X violation

My /usr/local partition is mounted with wxallowed.  Are these
warnings/errors expected?  My limited understanding of the wxallowed
flag was that it mean that programs were allowed to commit W^X
violations.

Below are some details about the environment I am running java in.
It is openbsd 6.0 running inside virtualbox on a windows pc.

>Environment:
System  : OpenBSD 6.0
Details : OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Architecture: OpenBSD.amd64
Machine : amd64

>How-To-Repeat:
do fresh openbsd install
verify that your /usr/local lies within a wxallowed partition
set your PKG_PATH
run pkg_add jdk (select jdk 8 from the menu)
add /usr/local/jdk-1.8.0 to your path

create a "hello world" java program(see example below).

public class Test {
public static void main(String[] args) {
System.out.println("hello world");
}
}

run javac Test.java

in one terminal window, tail -100f /var/log/messages

in another run java Test

observe the W^X violation being logged

>Fix:
programs seem like they work properly, however I wanted to check 
whether this logging is the expected behavior or no as it is a bit worrysome.

dmesg:
OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056899072 (1007MB)
avail mem = 1020502016 (973MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.85 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,LONG,LAHF,ABM,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 999MHz
cpu0: mwait min=64, max=64
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
"PNP0303" at acpi0 not configured
"PNP0F03" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "1" serial 0 type VBOX oem "innotek"
acpiac0 at acpi0: AC unit offline
acpivideo0 at acpi0: GFX0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 128-sector PIO, LBA, 16384MB, 33554432 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 
atapiscsi0 at pciide0 channel 1 drive 0 
scsibus1 at atapiscsi0: 2 targets 
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable 
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 
vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00 
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) 
wsdisplay0: screen 1-5 added (80x25, vt100 emulation) 
em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 1 int 19, address 
08:00:27:55:21:4c 
"InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0 not 
configured 
auich0 at pci0 dev 5 function 0 "Intel 82801AA AC97" rev 0x01: apic 1 int 21, 
ICH AC97 
ac97: codec id 0x83847600 (SigmaTel STAC9700) 
audio0 at auich0 
ohci0 at pci0 dev 6 function 0 "Apple Intrepid USB" rev 0x00: apic 1 int 22, 
version 1.0 
piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: apic 1 int 23 
iic0 at piixpm0 
em1 at pci0 dev 8 function 0 "Intel 82540EM" rev 0x02: apic 1 int 16, address 
08:00:27:63:6d:5f 
isa0 at pcib0 
isadma0 at isa0 
pckbc0 at isa0 port 0x60/5 irq 1 irq 12 
pckbd0 at pckbc0 (kbd slot) 
wskbd0 at pckbd0: console keyboard, using wsdisplay0 
pms0 at pckbc0 (aux slot) 
wsmouse0 at pms0 mux 0 
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "Apple OHCI root hub" rev 1.00/1.00 addr 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (24555dc8f83a2ce7.a) swap on wd0b dump on wd0b

usbdevs:

Re: mprotect W^X violation and JDK

2017-01-28 Thread Alex McWhirter
Java doesn't work with write xor execute and this is the kernels way of
letting you know. Java still runs because the partition is mounted with
wxallowed, but the kernel still prints the error to let you know that
Java isn't respecting a security feature.



Re: mprotect W^X violation and JDK

2017-01-28 Thread Stuart Henderson
On 2017-01-28, Currell Berry  wrote:
> Every time I start or stop a java program, I see something similar to
> the following logged in /var/log/messages 
>
> Jan 28 02:15:46 wtestvm3 /bsd: java(37284): mprotect W^X violation
>
> My /usr/local partition is mounted with wxallowed.  Are these
> warnings/errors expected?  My limited understanding of the wxallowed
> flag was that it mean that programs were allowed to commit W^X
> violations.

Expected in 6.0, it will go away in 6.1/-current.



netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-28 Thread Sven-Volker Nowarra
I am netbooting many systems, and last recently stepped on the issue, that I
had an amd64 and an i386 client in the same network. I wanted to boot them
into a "full" OpenBSD (not ramdisk kernel). That is not possible with the
default installation, cause pxeboot can not distinguish between these
Intel/AMD systems. DHCP server can distinguish by MAC address, but then when
pxeboot is loaded, the kernel is per default "bsd". This must clash either
with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry.
So I went through some older mailing list entries, adapted them, and updated
my meanwhile extensive netboot document. I updated this into a PDF, covering
many, many details (now ~50 pages). Wanted to give something back to the
community. The PDF is currently located here:
http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf



Re: Skype issue with office behind PF

2017-01-28 Thread Stuart Henderson
On 2017-01-27, lilit-aibolit  wrote:
> Hi list, I have an office behind NAT with PF.
> There are mostly Win7 workstations with
> different Skype versions but mostly with
> 7.3x or the latest versions.
> Two days ago any skype call started to drop
> after few seconds without any voice from
> opposite side.
> I got skype support which remotely looked
> at affected machines and after a while he
> resolved this by installing 7.15 version.
>
> However there is no trouble with skype
> by using it from other places of from personal
> hotspot 3G connection so I suspect here
> maybe be an issue with PF which somehow
> doesn't met to how last skype versions work.
> Any thoughts about that?
>
>

They might be sending packets which are passed by some NAT devices
but not by PF. Use "log" on your block rules and watch pflog0, see if
something is being blocked.

tcpdump -n -e -i pflog0



Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-28 Thread Jiri B
On Sat, Jan 28, 2017 at 06:41:34PM +0100, Sven-Volker Nowarra wrote:
> > Isn't better to use rewrite/file remapping instead of hacking pxeboot?
> > If an i386 machine would request /etc/boot.conf via tftp you could rewrite
> > it to (based on fact you know that that machine is i386 - during 
> > provisioning)
> > /etc/i386/boot.conf. For the client I suppose it would still think it gets
> > /etc/boot.conf.

> If this works, I could get rid of recompiling pxeboot everytime a
> new release comes out. Well, sometimes pxeboot also supports "older"
> OpenBSDs, but that is another topic.
> 

> I understand, the tftp server has a "root dir" for the client
> specified. In the dhcpd.conf I declare per client a MAC address and
> its filename (usually "/pxeboot"). The i386 pxeboot manual says:
> "pxeboot boot program will look for an /etc/boot.conf configuration
> file on the TFTP server." I didn't find a reference to a different
> sub structure...
> 
> Anyway, I tried a structure like you proposed, but pxeboot didn't
> find the boot.conf, and didn't even show the echo lines from this
> file (so useless to play with bsd location). This was my setup:
>
> location of boot.conf:
>   /tftpboot/etc/i386/boot.conf
> 
> $ cat /tftpboot/etc/i386/boot.conf
> echo ### 
> echo ### hello from tftpd@192.168.88.12, with /etc/i386/boot.conf ###
> echo ### 
> boot bsd.rd 
> 
> $ cat /etc/dhcpd.conf | grep filename
>filename "/pxeboot";
> 
> I also tried to play with the dhcpd.conf settings, by using a different 
> subdir for pxeboot, but I didn't get the system to find "his" boot.conf in 
> the i386 directory. 

It seems you missed part about tftpd rewrite/file remapping. The client will 
still
request /etc/boot.conf but you fake it via rewrite script.

man tftpd

 -r socket
 Issue filename rewrite requests to the specified UNIX domain
 socket.  tftpd will write lines in the format "IP OP filename",
 terminated by a newline, where IP is the client's IP address, and
 OP is one of "read" or "write".  tftpd expects replies in the
 format "filename" terminated by a newline.  All rewrite requests
 from the daemon must be answered (even if it is with the original
 filename) before the TFTP request will continue.  By default
 tftpd does not use filename rewriting.

j.



Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-28 Thread Sven-Volker Nowarra
> Am 28.01.2017 um 14:56 schrieb Jiri B :
>
> On Sat, Jan 28, 2017 at 12:17:40AM +0100, Sven-Volker Nowarra wrote:
>> I am netbooting many systems, and last recently stepped on the issue, that
I
>> had an amd64 and an i386 client in the same network. I wanted to boot them
>> into a "full" OpenBSD (not ramdisk kernel). That is not possible with the
>> default installation, cause pxeboot can not distinguish between these
>> Intel/AMD systems. DHCP server can distinguish by MAC address, but then
when
>> pxeboot is loaded, the kernel is per default "bsd". This must clash either
>> with i386 or amd64 architecture, whatever was dropped into tftpboot
direcotry.
>> So I went through some older mailing list entries, adapted them, and
updated
>> my meanwhile extensive netboot document. I updated this into a PDF,
covering
>> many, many details (now ~50 pages). Wanted to give something back to the
>> community. The PDF is currently located here:
>> http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf
>>
>
> Thanks, interesting document.
>
> Isn't better to use rewrite/file remapping instead of hacking pxeboot?
> If an i386 machine would request /etc/boot.conf via tftp you could rewrite
> it to (based on fact you know that that machine is i386 - during
provisioning)
> /etc/i386/boot.conf. For the client I suppose it would still think it gets
> /etc/boot.conf.
>
> j.

If this works, I could get rid of recompiling pxeboot everytime a new release
comes out. Well, sometimes pxeboot also supports "older" OpenBSDs, but that is
another topic.

I understand, the tftp server has a "root dir" for the client specified. In
the dhcpd.conf I declare per client a MAC address and its filename (usually
"/pxeboot"). The i386 pxeboot manual says: "pxeboot boot program will look for
an /etc/boot.conf configuration file on the TFTP server." I didn't find a
reference to a different sub structure...

Anyway, I tried a structure like you proposed, but pxeboot didn't find the
boot.conf, and didn't even show the echo lines from this file (so useless to
play with bsd location). This was my setup:

location of boot.conf:
  /tftpboot/etc/i386/boot.conf

$ cat /tftpboot/etc/i386/boot.conf
echo ###
echo ### hello from tftpd@192.168.88.12, with /etc/i386/boot.conf ###
echo ###
boot bsd.rd

$ cat /etc/dhcpd.conf | grep filename
   filename "/pxeboot";

I also tried to play with the dhcpd.conf settings, by using a different subdir
for pxeboot, but I didn't get the system to find "his" boot.conf in the i386
directory.



Re: mprotect W^X violation and JDK

2017-01-28 Thread Alex McWhirter
On Jan 28, 2017 2:02 PM, Christian Schulte  wrote:

  Am 01/28/17 um 10:04 schrieb Alex McWhirter:
  > Java doesn't work with write xor execute and this is the kernels
  way of
  > letting you know. Java still runs because the partition is mounted
  with
  > wxallowed, but the kernel still prints the error to let you know
  that
  > Java isn't respecting a security feature.
  >

  What should the VM do instead? It allocates memory, JIT compiles
  bytecode to machinecode and then executes that machinecode. Should it
  mprotect the memory after generating the machinecode? It would still
  execute code from memory it could write to.

  Regards,
  --
  Christian

Java's memory strategy would have to change. IIRC, java basically
allocates one big chunk of memory and the JVM uses it as a single heap. 
The most simple way I can think of would be to enable w^x support in the
java language itself and allow each java application to define whether or
not they use it and how they use it.
Another is to make the JVM smart enough to know what needs write and what
needs execute, but not both.
But that's up to Oracle im afraid, and im not certain of how much they
really care. Most likely it will be done when every other OS on the
planet starts enforcing w^x and Oracle kinda has to do it.



Re: mprotect W^X violation and JDK

2017-01-28 Thread Currell Berry
Ok, thank you.  That resolves my concern that something was broken.

Alex McWhirter writes:

> Java doesn't work with write xor execute and this is the kernels way
> of letting you know. Java still runs because the partition is mounted
> with wxallowed, but the kernel still prints the error to let you know
> that Java isn't respecting a security feature.



Re: mprotect W^X violation and JDK

2017-01-28 Thread Christian Schulte
Am 01/28/17 um 10:04 schrieb Alex McWhirter:
> Java doesn't work with write xor execute and this is the kernels way of
> letting you know. Java still runs because the partition is mounted with
> wxallowed, but the kernel still prints the error to let you know that
> Java isn't respecting a security feature.
> 

What should the VM do instead? It allocates memory, JIT compiles
bytecode to machinecode and then executes that machinecode. Should it
mprotect the memory after generating the machinecode? It would still
execute code from memory it could write to.

Regards,
-- 
Christian



Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-28 Thread Jiri B
On Sun, Jan 29, 2017 at 01:17:48AM +0200, li...@wrant.com wrote:
> Sample excerpts from host specific DHCP server config, for i386 and amd64:
> 
>   next-server 10.0.0.32;
>   filename "auto_upgrade";
> 
>   next-server 10.0.0.64;
>   filename "auto_upgrade";
> 
> Quoting autoinstall(8) for netbooting:  http://man.openbsd.org/autoinstall 
> 
>   On architectures where the filename statement is used to provide the
>   name of the file to netboot it is necessary to create symbolic links
>   called auto_install and auto_upgrade that point to the expected boot
>   program and to change the value of the filename statement in the
>   dhcpd.conf(5) file to be auto_install or auto_upgrade.
> 
>   # ln -s /tftpboot/i386/pxeboot  /tftpboot/i386/auto_upgrade
>   # ln -s /tftpboot/amd64/pxeboot /tftpboot/amd64/auto_upgrade
> 
> Needless to say, you need to populate the /tftpboot/{i386,amd64} locations
> with the system installation packages from the local mirror / compilation.
> 
> It is also quite easy to combine both the DHCP server and two instances of
> tftpd(8), started independently listening on 2 IP address aliases, serving
> pxeboot(8) respectively for i386 and amd64 systems stand alone each other.
> 
> See rcctl(8) to run a second copy of a daemon http://man.openbsd.org/rcctl
> 
>   The recommended way to run a second copy of a given daemon for a
>   different purpose is to create a symbolic link to its rc.d(8) control
>   script: 
> 
>   # ln -s /etc/rc.d/tftpd /etc/rc.d/tftpd2
>   # rcctl set tftpd status on
>   # rcctl set tftpd2 status on
>   # rcctl set tftpd flags -4 -l 10.0.0.32 /tftpboot/i386
>   # rcctl set tftpd2 flags -4 -l 10.0.0.64 /tftpboot/amd64
>   # rcctl start tftpd
>   # rcctl start tftpd2

Nice trick to define multiple tftp servers for each x86 architecture :)

Thanks!

j.



Re: netbooting OpenBSD (6.0) i386 and amd64 clients from one server

2017-01-28 Thread lists
Sat, 28 Jan 2017 00:17:40 +0100 Sven-Volker Nowarra 
> I am netbooting many systems, and last recently stepped on the issue, that I
> had an amd64 and an i386 client in the same network. I wanted to boot them
> into a "full" OpenBSD (not ramdisk kernel). That is not possible with the
> default installation, cause pxeboot can not distinguish between these
> Intel/AMD systems.

Hi Sven-Volker, Jiri,

I am also booting over network many systems in the same network, including
i386 and amd64 systems.  It is in fact quite possible to achieve this with
the default installation, with the help of the DHCP next-server statement.

> DHCP server can distinguish by MAC address, but then when
> pxeboot is loaded, the kernel is per default "bsd". This must clash either
> with i386 or amd64 architecture, whatever was dropped into tftpboot direcotry.

Quoting dhcpd.conf(5), please see here:  http://man.openbsd.org/dhcpd.conf

next-server server-name;

  The next-server statement is used to specify the host address of the
  server from which the initial boot file (specified in the filename
  statement) is to be loaded. server-name should be a numeric IP address
  or a domain name. If no next-server parameter applies to a given
  client, the DHCP server's IP address is used.

Sample excerpts from host specific DHCP server config, for i386 and amd64:

next-server 10.0.0.32;
filename "auto_upgrade";

next-server 10.0.0.64;
filename "auto_upgrade";

Quoting autoinstall(8) for netbooting:  http://man.openbsd.org/autoinstall 

  On architectures where the filename statement is used to provide the
  name of the file to netboot it is necessary to create symbolic links
  called auto_install and auto_upgrade that point to the expected boot
  program and to change the value of the filename statement in the
  dhcpd.conf(5) file to be auto_install or auto_upgrade.

# ln -s /tftpboot/i386/pxeboot  /tftpboot/i386/auto_upgrade
# ln -s /tftpboot/amd64/pxeboot /tftpboot/amd64/auto_upgrade

Needless to say, you need to populate the /tftpboot/{i386,amd64} locations
with the system installation packages from the local mirror / compilation.

It is also quite easy to combine both the DHCP server and two instances of
tftpd(8), started independently listening on 2 IP address aliases, serving
pxeboot(8) respectively for i386 and amd64 systems stand alone each other.

See rcctl(8) to run a second copy of a daemon http://man.openbsd.org/rcctl

  The recommended way to run a second copy of a given daemon for a
  different purpose is to create a symbolic link to its rc.d(8) control
  script: 

# ln -s /etc/rc.d/tftpd /etc/rc.d/tftpd2
# rcctl set tftpd status on
# rcctl set tftpd2 status on
# rcctl set tftpd flags -4 -l 10.0.0.32 /tftpboot/i386
# rcctl set tftpd2 flags -4 -l 10.0.0.64 /tftpboot/amd64
# rcctl start tftpd
# rcctl start tftpd2

For the list of the flags for tftpd(8), see:  http://man.openbsd.org/tftpd

When you need to upgrade a system, link the boot.conf to a file with this:

boot tftp:/bsd.rd

When done, link it back the boot.conf file to a file that has the generic:

boot hd0a:/bsd

This way you always net boot the system, then make it auto_upgrade, or run
the already installed system from the first hard disk where the system is.

Of course you may want to adjust these as per your environment and set up.
I would be glad if you could share an idea how to toggle boot.conf better.

I would be further much more grateful if there is in the near future a way
to provide automatic response file for local install for the serve system.

> So I went through some older mailing list entries, adapted them, and updated
> my meanwhile extensive netboot document. I updated this into a PDF, covering
> many, many details (now ~50 pages). Wanted to give something back to the
> community. The PDF is currently located here:
> http://nowarra.ch/Volker/netboot_OpenBSD/170127_netbooting_OpenBSD60.pdf

Nice read, thank you.  Hopefully you could further extend it, for multiple
concurrent network boot environments for simpler setup w/o custom patches.

Kind regards,
Anton



Kernel panic after upgrade -CURRENT

2017-01-28 Thread kayasaman
Hi,
A very strange issue...
After the previous update of CURRENT I started to have issues with ftpproxy not 
loading some directories, an example being shrubbery.net rancid directory.
Today I attempted an upgrade to see if that might kick things into gear and now 
my OBSD machine won't boot and Kernel panics upon starting network services.
Here is an image of the hang:
https://www.dropbox.com/s/74e5mjg7sn8jrck/20170129_025823.jpg?dl=0
As instructed by the terminal I read through:
https://www.openbsd.org/ddb.html
However, I am unable to input anything on the keyboard post hang?? Basically my 
keyboard becomes unresponsive and any key pressed does nothing.
I am able to boot into Single User mode without panic but that's about it.
What can I do to resolve this? Or what more info could I provide that is 
useful, considering that I am unable to run any ddb commands??
Thanks.
Kaya 


Sent from my Samsung Galaxy smartphone.



Re: Kernel panic after upgrade -CURRENT

2017-01-28 Thread Hrvoje Popovski
On 29.1.2017. 4:13, kayasaman wrote:
> Hi,
> A very strange issue...
> After the previous update of CURRENT I started to have issues with ftpproxy 
> not loading some directories, an example being shrubbery.net rancid directory.
> Today I attempted an upgrade to see if that might kick things into gear and 
> now my OBSD machine won't boot and Kernel panics upon starting network 
> services.
> Here is an image of the hang:
> https://www.dropbox.com/s/74e5mjg7sn8jrck/20170129_025823.jpg?dl=0
> As instructed by the terminal I read through:
> https://www.openbsd.org/ddb.html
> However, I am unable to input anything on the keyboard post hang?? Basically 
> my keyboard becomes unresponsive and any key pressed does nothing.
> I am able to boot into Single User mode without panic but that's about it.
> What can I do to resolve this? Or what more info could I provide that is 
> useful, considering that I am unable to run any ddb commands??
> Thanks.
> Kaya 
> 
> 
> Sent from my Samsung Galaxy smartphone.
> 

Hi,

send this report to b...@openbsd.org. Please see this mail thread

https://www.mail-archive.com/tech@openbsd.org/msg36980.html