Re: Documentation patches?
Hi Chris, Chris McGee wrote on Mon, Dec 17, 2018 at 10:00:27PM -0500: > I'd like to submit some info for the install64.octeon documentation. > I just installed 6.4 on a newer EdgeRouter than the documentation was > written for. The instructions in the install document are probably not > enough to get the average user booted on that particular piece of > hardware. I'd like to document the install while I still remember it. > Can I submit a patch somewhere? When asking where to send a patch, always include the patch itself unless it fixes a security vulnerability and has to be kept confidential until it is properly committed. Sending the patch rather than asking where to send it saves one iteration. For OpenBSD, unless you are sure that some other destination is even better in a particular case, send patches to . Include enough information such that developers can easily understand which problem you are trying to fix and how you tested your patch. Yours, Ingo
Re: Cheaper alternatives for APC UPS
On Mon, Dec 17, 2018 at 09:47:25PM +0100, Radek wrote:
> Hello,
>
> could you recommend me any UPS brands *cheaper* than APC that are
> fully supported in OpenBSD?
> I always use APC, managing them via USB and apcupsd(both servers and
> clients) and PowerChute(windows clients). It works like a charm.
> APC is quite expensive brand so I am looking for any cheaper
> alternatives.
I am not sure about "supported", but for a while I used Fideltronik
and was satisfied (battery failed after some years of good job). Alas,
it gave approximated sinus, and I want true one nowadays. The only
choice available in the limits of my budget is either used APC or
another brand, new European-by-the-name-seemingly. I used a second
hand APC (1000-something, blinking leds model), after some years
batteries died and I decided to try this other option. It worked fine
for two years, then died. Upon inspection I found that certain part
inside looked like burned, with ash on it (possibly burned
plastic). Also, I cannot bet on it because I stuffed the battery
somewhere ("hey I can reuse that for a hobby!") and am not sure where
it is, but I would say there was single 6v unit inside. As far as I
can tell, the ups never reported more than 50% load, so I do not think I
overworked it.
Anyway, I could easily lift its battery on two fingers, maybe
three. In both APCs (I am on another second hand now, again
1000-something but now with lcd display) there are two 12v batts (I
think) and I would rather not want to lift any of them other than on
full arm. The first second-hand will probably be inspected and turned
into spare unit, because the current one will finish itself too, one
day. But the batts can be replaced in both models.
HTH
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Documentation patches?
Hi: I'd like to submit some info for the install64.octeon documentation. I just installed 6.4 on a newer EdgeRouter than the documentation was written for. The instructions in the install document are probably not enough to get the average user booted on that particular piece of hardware. I'd like to document the install while I still remember it. Can I submit a patch somewhere? Thanks! --Chris
Re: radeondrm failure on amd64 but not on i386?
Found a cheap card on eBay, dmesg shows it as ATI Radeon HD 7470, working well in OpenBSD 6.4-current (GENERIC.MP) #499: Mon Dec 10 11:33:10 MST 2018. Allan Allan Streib writes: > Still having this issue on -current as of Dec10. machdep.allowaperture=2 > does get me past this, but am seeing weird behavior, some regions of > screens/terminals not painting or refreshing. > > So, as this is a major inconvenience I am looking to update the video > card. > > Any recommendations for a low-profile card that is working on > 6.4/current? > > Thanks, > > Allan
Re: netstat *:* udp sockets
Sebastian Benoit wrote: > > > or what should it show? Only sockets that are bound > > > but not connected (local port != 0 but remote addr/port = 0)? > > > > see my other mail for that diff. > > here. Ok for one or the other? as a non expert, this matches my expectation of what "listening" would map onto for udp. ok fwiw.
Re: Cheaper alternatives for APC UPS
Hi Radek I had a lot of problems such as overheating, and much shorter lifespan of batteries with cheaper brands. I'm not a fan of branded overprices but I need my server to run 24/7 We had some cyberpower for workstations and 2 started leaking battery acid after 8 months R -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Radek Sent: 17 December 2018 20:47 To: misc@openbsd.org Subject: Cheaper alternatives for APC UPS Hello, could you recommend me any UPS brands *cheaper* than APC that are fully supported in OpenBSD? I always use APC, managing them via USB and apcupsd(both servers and clients) and PowerChute(windows clients). It works like a charm. APC is quite expensive brand so I am looking for any cheaper alternatives. Thanks! -- radek
Cheaper alternatives for APC UPS
Hello, could you recommend me any UPS brands *cheaper* than APC that are fully supported in OpenBSD? I always use APC, managing them via USB and apcupsd(both servers and clients) and PowerChute(windows clients). It works like a charm. APC is quite expensive brand so I am looking for any cheaper alternatives. Thanks! -- radek
Re: TLS suddenly not working over IKED site-to-site
On Sat, Dec 15, 2018 at 06:18:39PM -0600, Theodore Wynnychenko wrote:
> On the local gateway:
>
> 17:37:00.199269 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 >
> 172.30.6.201.443: S 3823001077:3823001077(0) win 16384 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 48604571 0> (encap)
>
> 17:37:00.235313 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
> 172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384 65496,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 730029501 48604571> (DF)
> (encap)
>
> 17:37:00.235335 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 >
> 172.30.6.201.443: . ack 1 win 256
> (encap)
>
> 17:37:00.236086 (unprotected): SPI 0x54ab: 172.30.1.20.20692 >
> 172.30.6.201.443: P 1:197(196) ack 1 win 256 730029501> (encap)
>
> 17:37:01.726509 (unprotected): SPI 0x54ab: 172.30.1.20.20692 >
> 172.30.6.201.443: P 1:197(196) ack 1 win 256 730029501> (encap)
>
> 17:37:04.726571 (unprotected): SPI 0x54ab: 172.30.1.20.20692 >
> 172.30.6.201.443: P 1:197(196) ack 1 win 256 730029501> (encap)
This looks odd to me. Why unprotected?
> 17:37:10.726697 (unprotected): SPI 0x54ab: 172.30.1.20.20692 >
> 172.30.6.201.443: FP 1:197(196) ack 1 win 256 730029516> (encap)
>
> 17:37:11.724643 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
> 172.30.1.20.20692: F 1:1(0) ack 1 win 271 48604571> (DF) (encap)
>
> 17:37:11.724680 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 >
> 172.30.6.201.443: F 197:197(0) ack 2 win 256 730029524> (encap)
>
> 17:37:11.759035 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
> 172.30.1.20.20692: . ack 1 win 271
> (DF) (encap)
Packet fragmentation is something to investigate.
>
> But, tcpdump of enc0 on the remote gateway only shows:
>
> 17:37:00.207517 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 >
> 172.30.6.201.443: S 3823001077:3823001077(0) win 16384 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 48604571 0> (encap)
>
> 17:37:00.207551 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
> 172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384 65496,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 730029501 48604571> (DF)
> (encap)
>
> 17:37:00.244461 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 >
> 172.30.6.201.443: . ack 1 win 256
> (encap)
>
> 17:37:07.792702 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 >
> 172.30.6.201.443: F 197:197(0) ack 1 win 256 730029501> (encap)
>
> 17:37:07.792724 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 >
> 172.30.1.20.20692: . ack 1 win 271 48604571,nop,nop,sack 1 {197:197} > (DF) (encap)
> Needless to say, if I try these connections WITHOUT traversing the iked
> vpn, the openssl s_client to s_server connection works as expected.
>
> Not being in any way an expert on these things, I cannot understand why
> "regular" tcp packets are able to traverse the VPN and emerge on the other
> side, while tcp pakets to the same port attempting to establish a secure
> connection are lost. Why are the tcp PUSH data packets that leave the
> local gateway on enc0 never seen on the remote gateway's ecn0?
>
> I am really hoping that somebody has some sort idea of what I can do to
> fix whatever it is that I have broken. I will be happy to send more
> specific information, I just don't know what that might be.
I'm not well versed in these issues but if I were in your shoes I would
1) Figure out why those packets were unprotected. (Could be normal for all I
know, but in a quick test on my enc0 I didn't see any packets like that.)
2) Make sure the tunnel handles fragmentation correctly. Are fragments being
dropped? Are reassembled fragments being dropped?
2.a) Relatedly, make sure the tunnel handles pMTU discovery. Do ICMP
Fragmentation Needed packets make it back through the tunnel? pMTU and ICMP
issues are very common with IPSec tunnels. IME most people "fix" these
issues by forcing a lower MSS or setting a lower MTU at the ingress point
rather than properly configuring routing so ICMP errors are properly routed.
I've experienced this issue myself and had to learn the hard way.
3) From an earlier post it looks like you're using ipcomp. You should remove
this complication while debugging. It's possible ipcomp is hiding MTU
issues.
Re: netstat *:* udp sockets
On Mon, Dec 17, 2018 at 06:05:00PM +0100, Sebastian Benoit wrote:
> Sebastian Benoit(benoit-li...@fb12.de) on 2018.12.17 17:59:49 +0100:
> > Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.12.17 08:25:07 +0100:
> > > On Sun, Dec 16, 2018 at 05:09:06PM -0500, Ted Unangst wrote:
> > > > Claudio Jeker wrote:
> > > > > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote:
> > > > > > Philip Guenther wrote:
> > > > > > > And, perhaps more directly, how would I block this in pf.conf?
> > > > > > > >
> > > > > > >
> > > > > > > Excellent choice, blocking dhclient from receiving the leases
> > > > > > > that it
> > > > > > > requests.
> > > > > > > "What problem are you trying to solve?"
> > > > > >
> > > > > > Well, this may be something of a lost cause, but I would prefer
> > > > > > that chrome
> > > > > > not listen for stuff I don't understand. It listens on port 5353 as
> > > > > > well, for
> > > > > > mDNS, and I can block that easily enough. It's the socket without a
> > > > > > port
> > > > > > that's giving me trouble.
> > > > >
> > > > > But a socket without a port is not listening on anything. It will not
> > > > > get
> > > > > any packets. It does not need to be filtered. This is how UDP works,
> > > > > it is
> > > > > a connectionless protocol.
> > > >
> > > > ok, thank you, I was confused because they show up in netstat -ln too.
> > > > I guess
> > > > that's just historic how it is behavior.
> >
> > nothing historic about it, i added -l last year.
> >
> > but i wanted to keep it simple, i thought that its obvious what "listening"
> > sockets mean in this context (i.e. that it only really is a concept in TCP).
> >
> > > I guess we should change that. Problem is that UDP does not support
> > > listen(2) and so there is no listening state. Should netstat exclude all
> > > of UDP when using -l
> >
> > here is a diff for that
> >
> > > or what should it show? Only sockets that are bound
> > > but not connected (local port != 0 but remote addr/port = 0)?
> >
> > see my other mail for that diff.
>
> here. Ok for one or the other?
>
> (netstat_l_udp_only_otherside_zero.diff)
>
> diff --git usr.bin/netstat/inet.c usr.bin/netstat/inet.c
> index e8e2a4dcd4f..d378bfe6280 100644
> --- usr.bin/netstat/inet.c
> +++ usr.bin/netstat/inet.c
> @@ -225,6 +225,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
> int addrlen = 22;
> int isany = 0;
> int istcp = 0;
> + int isudp = 0;
> int isip6 = 0;
>
> /* XXX should fix kinfo_file instead but not now */
> @@ -282,6 +283,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
> case IPPROTO_UDP:
> name = "udp";
> name6 = "udp6";
> + isudp = 1;
> break;
> case IPPROTO_DIVERT:
> name = "divert";
> @@ -303,6 +305,9 @@ netdomainpr(struct kinfo_file *kf, int proto)
> if (!aflag && lflag && istcp &&
> kf->t_state != TCPS_LISTEN)
> return;
> + if (!aflag && lflag && isudp &&
> + (kf->inp_lport == 0 || kf->inp_fport != 0))
> + return;
>
> if (af != kf->so_family || type != kf->so_type) {
> af = kf->so_family;
> @@ -310,7 +315,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
> printf("Active Internet connections");
> if (aflag)
> printf(" (including servers)");
> - else if (lflag)
> + else if (lflag && (istcp||isudp))
Needs some spaces ^^ here
> printf(" (only servers)");
> putchar('\n');
> if (Aflag) {
>
Apart from that OK claudio@
--
:wq Claudio
Re: netstat *:* udp sockets
Sebastian Benoit(benoit-li...@fb12.de) on 2018.12.17 17:59:49 +0100:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.12.17 08:25:07 +0100:
> > On Sun, Dec 16, 2018 at 05:09:06PM -0500, Ted Unangst wrote:
> > > Claudio Jeker wrote:
> > > > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote:
> > > > > Philip Guenther wrote:
> > > > > > And, perhaps more directly, how would I block this in pf.conf?
> > > > > > >
> > > > > >
> > > > > > Excellent choice, blocking dhclient from receiving the leases that
> > > > > > it
> > > > > > requests.
> > > > > > "What problem are you trying to solve?"
> > > > >
> > > > > Well, this may be something of a lost cause, but I would prefer that
> > > > > chrome
> > > > > not listen for stuff I don't understand. It listens on port 5353 as
> > > > > well, for
> > > > > mDNS, and I can block that easily enough. It's the socket without a
> > > > > port
> > > > > that's giving me trouble.
> > > >
> > > > But a socket without a port is not listening on anything. It will not
> > > > get
> > > > any packets. It does not need to be filtered. This is how UDP works, it
> > > > is
> > > > a connectionless protocol.
> > >
> > > ok, thank you, I was confused because they show up in netstat -ln too. I
> > > guess
> > > that's just historic how it is behavior.
>
> nothing historic about it, i added -l last year.
>
> but i wanted to keep it simple, i thought that its obvious what "listening"
> sockets mean in this context (i.e. that it only really is a concept in TCP).
>
> > I guess we should change that. Problem is that UDP does not support
> > listen(2) and so there is no listening state. Should netstat exclude all
> > of UDP when using -l
>
> here is a diff for that
>
> > or what should it show? Only sockets that are bound
> > but not connected (local port != 0 but remote addr/port = 0)?
>
> see my other mail for that diff.
here. Ok for one or the other?
(netstat_l_udp_only_otherside_zero.diff)
diff --git usr.bin/netstat/inet.c usr.bin/netstat/inet.c
index e8e2a4dcd4f..d378bfe6280 100644
--- usr.bin/netstat/inet.c
+++ usr.bin/netstat/inet.c
@@ -225,6 +225,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
int addrlen = 22;
int isany = 0;
int istcp = 0;
+ int isudp = 0;
int isip6 = 0;
/* XXX should fix kinfo_file instead but not now */
@@ -282,6 +283,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
case IPPROTO_UDP:
name = "udp";
name6 = "udp6";
+ isudp = 1;
break;
case IPPROTO_DIVERT:
name = "divert";
@@ -303,6 +305,9 @@ netdomainpr(struct kinfo_file *kf, int proto)
if (!aflag && lflag && istcp &&
kf->t_state != TCPS_LISTEN)
return;
+ if (!aflag && lflag && isudp &&
+ (kf->inp_lport == 0 || kf->inp_fport != 0))
+ return;
if (af != kf->so_family || type != kf->so_type) {
af = kf->so_family;
@@ -310,7 +315,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
printf("Active Internet connections");
if (aflag)
printf(" (including servers)");
- else if (lflag)
+ else if (lflag && (istcp||isudp))
printf(" (only servers)");
putchar('\n');
if (Aflag) {
Re: netstat *:* udp sockets
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.12.17 08:25:07 +0100:
> On Sun, Dec 16, 2018 at 05:09:06PM -0500, Ted Unangst wrote:
> > Claudio Jeker wrote:
> > > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote:
> > > > Philip Guenther wrote:
> > > > > And, perhaps more directly, how would I block this in pf.conf?
> > > > > >
> > > > >
> > > > > Excellent choice, blocking dhclient from receiving the leases that it
> > > > > requests.
> > > > > "What problem are you trying to solve?"
> > > >
> > > > Well, this may be something of a lost cause, but I would prefer that
> > > > chrome
> > > > not listen for stuff I don't understand. It listens on port 5353 as
> > > > well, for
> > > > mDNS, and I can block that easily enough. It's the socket without a port
> > > > that's giving me trouble.
> > >
> > > But a socket without a port is not listening on anything. It will not get
> > > any packets. It does not need to be filtered. This is how UDP works, it is
> > > a connectionless protocol.
> >
> > ok, thank you, I was confused because they show up in netstat -ln too. I
> > guess
> > that's just historic how it is behavior.
nothing historic about it, i added -l last year.
but i wanted to keep it simple, i thought that its obvious what "listening"
sockets mean in this context (i.e. that it only really is a concept in TCP).
> I guess we should change that. Problem is that UDP does not support
> listen(2) and so there is no listening state. Should netstat exclude all
> of UDP when using -l
here is a diff for that
> or what should it show? Only sockets that are bound
> but not connected (local port != 0 but remote addr/port = 0)?
see my other mail for that diff.
(netstat_l_only_tcp.diff)
diff --git usr.bin/netstat/main.c usr.bin/netstat/main.c
index 17c889768a2..6bf155205ee 100644
--- usr.bin/netstat/main.c
+++ usr.bin/netstat/main.c
@@ -189,6 +189,8 @@ main(int argc, char *argv[])
break;
case 'l':
lflag = 1;
+ tp = knownname("tcp");
+ pflag = 1;
break;
case 'M':
memf = optarg;
@@ -203,7 +205,8 @@ main(int argc, char *argv[])
nflag = 1;
break;
case 'p':
- if ((tp = name2protox(optarg)) == NULL) {
+ if (pflag == 0 &&
+ (tp = name2protox(optarg)) == NULL) {
(void)fprintf(stderr,
"%s: %s: unknown protocol\n",
__progname, optarg);
Re: Automated remote install
On Mon, Dec 17, 2018 at 01:36:57PM +, secli...@boxdan.com wrote: > On Mon, Dec 17, 2018 at 10:22:56AM -0200, Daniel Bolgheroni wrote: > > Maybe ansible is not the answer here. > > You are probably correct. Do you know a better way? If you're going to run on some public cloud, they usually offer the possibility of keeping a custom image you provide, and use this image to deploy new VMs based on it. You can do a normal install and customize it adding the python package (you do not need ansible on the target machine, just python) and your public ssh key for the user ansible will use to connect. This customization can be done manually or using siteXX.tgz and install.site that OpenBSD provides: https://www.openbsd.org/faq/faq4.html#site >From here you should be able to point ansible from the control machine to the target VM, and run your playbook to further customize your installation. Of course that, at this point, the network should be already up. This depends on your public cloud, but usually a 'dhcp' inside your hostname.if(5) will do. But note again this is not a fully-automated installation using ansible, which isn't trivial on any OS. But it helps a lot. -- db
Re: Odp.: Automated remote install
Thank you! That is very helpful.
On Mon, Dec 17, 2018 at 04:29:35PM +0200, cho...@jtan.com wrote:
Below is my work-in-progress code to take an openbsd cdXX.iso and inject the
bare minimum necessary to autoinstall from a configuration file embedded in the
image (it also reconfigures the console to run over the serial port -
especially useful on a VM). There are no doubt better ways to do much of this
but it's enough for me for the time being.
You will need an answers file. To automatically partition you will need to
include this answer:
URL to autopartitioning template for disklabel = file:/disklabel.template
Matthew
#!/bin/sh
# TODO: Get version from "$iso"
version=6.3
eval size=\$size_"$scheme"
eval sets=\$sets_"$scheme"
# OpenBSD's partitioning will be performed by the installer
# Only this stuff needs root, and only because the cd is _mounted_:
root vnconfig $loop "$iso"
root mount -o ro /dev/${loop}a "$mount"
# Needs root because bsd.rd is 750
root rsync -a --delete --exclude=TRANS.TBL "$mount"/ "$where"/cd/
root chmod -R a+rwX "$where"/cd
root umount "$mount"
root vnconfig -u $loop
echo set tty com0 >> "$where"/cd/etc/boot.conf
elfrdsetroot -x "$where"/cd/$version/amd64/bsd.rd "$where"/ramdisk
root vnconfig $loop "$where"/ramdisk
root mount /dev/${loop}a "$mount"
root cp "$libimage"/installer.openbsd "$mount"/auto_install.conf # .type for
sets? ed?
root ed -s "$mount"/auto_install.conf <" \
-V "OpenBSD/amd64 ${OSREV} boot-only CD" \
-b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog\
"$where"/cd
rm -fr "$where"/cd "$where"/ramdisk &
# Questions: At what point does KARL clean up the other kernel's files?
# When to set proxy and where?
# syspatch on first boot
# Password must be 13 *s
Re: Automated remote install
On Mon, Dec 17, 2018 at 10:22:56AM -0200, Daniel Bolgheroni wrote: Maybe ansible is not the answer here. You are probably correct. Do you know a better way?
Re: Odp.: Automated remote install
Below is my work-in-progress code to take an openbsd cdXX.iso and inject the
bare minimum necessary to autoinstall from a configuration file embedded in the
image (it also reconfigures the console to run over the serial port -
especially useful on a VM). There are no doubt better ways to do much of this
but it's enough for me for the time being.
You will need an answers file. To automatically partition you will need to
include this answer:
URL to autopartitioning template for disklabel = file:/disklabel.template
Matthew
#!/bin/sh
# TODO: Get version from "$iso"
version=6.3
eval size=\$size_"$scheme"
eval sets=\$sets_"$scheme"
# OpenBSD's partitioning will be performed by the installer
# Only this stuff needs root, and only because the cd is _mounted_:
root vnconfig $loop "$iso"
root mount -o ro /dev/${loop}a "$mount"
# Needs root because bsd.rd is 750
root rsync -a --delete --exclude=TRANS.TBL "$mount"/ "$where"/cd/
root chmod -R a+rwX "$where"/cd
root umount "$mount"
root vnconfig -u $loop
echo set tty com0 >> "$where"/cd/etc/boot.conf
elfrdsetroot -x "$where"/cd/$version/amd64/bsd.rd "$where"/ramdisk
root vnconfig $loop "$where"/ramdisk
root mount /dev/${loop}a "$mount"
root cp "$libimage"/installer.openbsd "$mount"/auto_install.conf # .type for
sets? ed?
root ed -s "$mount"/auto_install.conf <" \
-V "OpenBSD/amd64 ${OSREV} boot-only CD" \
-b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog\
"$where"/cd
rm -fr "$where"/cd "$where"/ramdisk &
# Questions: At what point does KARL clean up the other kernel's files?
# When to set proxy and where?
# syspatch on first boot
# Password must be 13 *s
Odp.: Odp.: Automated remote install
Oh, I see. So in case of installing OpenBSD on remote VPS article https://www.tumfatig.net/20161124/encrypted-openbsd-6-0-in-the-ovh-cloud/ was helpful for me. And I bet this can be automated with scripting or Ansible. To make whole provess even easier you may omit encryption steps. -- Kamil Monticolo Od: secli...@boxdan.com Wysłane: poniedziałek, 17 grudnia 2018 14:34:37 Do: Kamil Monticolo DW: misc@openbsd.org Temat: Re: Odp.: Automated remote install On Mon, Dec 17, 2018 at 12:55:44PM +, Kamil Monticolo wrote: >I was using (suprise) OpenBSD-based PXE server to install OpenBSD on >vm/baremetal using autoinstall(8) feature. > >There are a few arts describing the process, e.g. >https://www.bsdnow.tv/tutorials/autoinstall > >I also save some snippets in gist here: >https://gist.github.com/kmonticolo/2b4ffc7ace4c5b09f0bf8075693161dc Thank you. That looks primarily useful for people who control the network environment as well (DHCP server). In this case, my application is installing OpenBSD on remote servers (dedicated or VPS) hosted on networks which I do not otherwise control.
Re: Odp.: Automated remote install
On Mon, Dec 17, 2018 at 12:55:44PM +, Kamil Monticolo wrote: I was using (suprise) OpenBSD-based PXE server to install OpenBSD on vm/baremetal using autoinstall(8) feature. There are a few arts describing the process, e.g. https://www.bsdnow.tv/tutorials/autoinstall I also save some snippets in gist here: https://gist.github.com/kmonticolo/2b4ffc7ace4c5b09f0bf8075693161dc Thank you. That looks primarily useful for people who control the network environment as well (DHCP server). In this case, my application is installing OpenBSD on remote servers (dedicated or VPS) hosted on networks which I do not otherwise control.
Re: Automated remote install
On Mon, Dec 17, 2018 at 09:23:08AM +, secli...@boxdan.com wrote: > Has anyone successfully automated (i.e with Ansible/etc) the process of > installing OpenBSD on a remote server? > > The most recent attempts at remote installation (manual or automated) that I > was able to find, are fairly old: > https://jcs.org/notaweblog/2014/09/12/remotely_installing_openbsd_qemu > https://github.com/jedisct1/yaifo > https://www.dim13.org/Install-OpenBSD-on-remote-host-without-KVM > http://frankgroeneveld.nl/2014/04/13/remote-installation-of-openbsd-from-linux/ > > jcs indicates that his QEMU-based method demands knowing what kind of > network card is in the server. This seems hard to automate. I don't know how you would do this with ansible, since the node requirement is at least a network connection already running, ssh (which is not in bsd.rd) and python (which is only on ports). In another words, a pretty complete OS setup already. See this: https://docs.ansible.com/ansible/2.7/installation_guide/intro_installation.html#managed-node-requirements And some problems Joshua Stein described he could hit with YAIFO (the first link you posted) would also apply here. Note that this isn't limited to OpenBSD. Maybe ansible is not the answer here. Cheers, -- db
Re: install portslist?
On Dec 14, 2018 10:40 AM, Marcus MERIGHI wrote: > > Hello, > > rsyk...@disroot.org (Rudolf Sykora), 2018.12.14 (Fri) 15:40 (CET): > > odin$ pwd > > /usr/ports > > > > odin$ make search key=texmacs > > Please install portslist > > pkg_add portslist > > *** Error 1 in /usr/ports (Makefile:80 '/usr/local/share/ports-INDEX': > > @exit 1) > > > > odin$ doas pkg_add portslist > > portslist-6.8: ok > > odin$ make search key=texmacs > > Please install portslist > > portslist does not bring back "make search key=" but gives you a flat The FAQ disagrees with you. > text file: > > $ pkg_info -L portslist > $ less /usr/local/share/sqlports.list > > Marcus > > > pkg_add portslist > > *** Error 1 in /usr/ports (Makefile:80 '/usr/local/share/ports-INDEX': > > @exit 1) > > > > odin$ pkg_info -Q portslist > > portslist-6.8 (installed) > > > > odin$ make search key=texmacs > > Please install portslist > > pkg_add portslist > > *** Error 1 in /usr/ports (Makefile:80 '/usr/local/share/ports-INDEX': > > @exit 1) > > > > > > Is this expected? What am I doing wrong? > > > > Thanks > > Ruda > > >
Odp.: Automated remote install
I was using (suprise) OpenBSD-based PXE server to install OpenBSD on vm/baremetal using autoinstall(8) feature. There are a few arts describing the process, e.g. https://www.bsdnow.tv/tutorials/autoinstall I also save some snippets in gist here: https://gist.github.com/kmonticolo/2b4ffc7ace4c5b09f0bf8075693161dc -- Kamil Monticolo Od: owner-m...@openbsd.org w imieniu użytkownika secli...@boxdan.com Wysłane: poniedziałek, 17 grudnia 2018 10:23:08 Do: misc@openbsd.org Temat: Automated remote install Has anyone successfully automated (i.e with Ansible/etc) the process of installing OpenBSD on a remote server? The most recent attempts at remote installation (manual or automated) that I was able to find, are fairly old: https://jcs.org/notaweblog/2014/09/12/remotely_installing_openbsd_qemu https://github.com/jedisct1/yaifo https://www.dim13.org/Install-OpenBSD-on-remote-host-without-KVM http://frankgroeneveld.nl/2014/04/13/remote-installation-of-openbsd-from-linux/ jcs indicates that his QEMU-based method demands knowing what kind of network card is in the server. This seems hard to automate. -Frank
Re: Automated remote install
Den mån 17 dec. 2018 kl 11:19 skrev : > > Has anyone successfully automated (i.e with Ansible/etc) the process of > installing OpenBSD on a remote server? > > jcs indicates that his QEMU-based method demands knowing what kind of network > card is in the server. This seems hard to automate. I think you can prepopulate a ton of /etc/hostname.0 configs all saying "dhcp" and cover a wide range of emulated network hardware in order to get a reachable machine for which later configs (like more ifs and so forth) can be set. -- May the most significant bit of your life be positive.
Re: IPv6 Multicast Listener Discovery - Listing and Disabling Group Membership
On 1/10/18 17:18, Aham Brahmasmi wrote: > Hello misc, > > Running 6.4-beta from approximately a week ago. > > 1) How to determine the IPv6 multicast groups which have been joined by > a particular interface? Use ifmcstat But you need to install the corresponding package first. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Automated remote install
Has anyone successfully automated (i.e with Ansible/etc) the process of installing OpenBSD on a remote server? The most recent attempts at remote installation (manual or automated) that I was able to find, are fairly old: https://jcs.org/notaweblog/2014/09/12/remotely_installing_openbsd_qemu https://github.com/jedisct1/yaifo https://www.dim13.org/Install-OpenBSD-on-remote-host-without-KVM http://frankgroeneveld.nl/2014/04/13/remote-installation-of-openbsd-from-linux/ jcs indicates that his QEMU-based method demands knowing what kind of network card is in the server. This seems hard to automate. -Frank
Re: Machine hangs on DDB, unable to get info to send in bug report
On 2018-12-16, Michael Pagano wrote: > Hello, > > I seem to be having a difficulty with DDB. I am intending to send in a > bug report for a kernel panic I'm having, but unfortunately, I am unable > to acquire the proper details necessary to send in a meaningful report > because of DDB hanging when this kernel panic occurs. Is there a > way to obtain this information (i. e., traceback and ps output) on the > next boot so I could make said report? > > Thank you very much in advance. > Does "sysctl machdep.forceukbd=1" help? If you have "ddb.console=1" (which must be set at boot e.g. via sysctl.conf - you can't do that later at runtime) you can test entry without a panic by pressing ctrl-alt-esc. If not, set ddb.panic=0, it will print some things, attempt to save a kernel core to disk, and reboot - if you're watching when it happens hopefully you can take a photo whilr it's writing to disk.
Re: install portslist?
On 2018-12-14, Marcus MERIGHI wrote: > Hello, > > rsyk...@disroot.org (Rudolf Sykora), 2018.12.14 (Fri) 15:40 (CET): >> odin$ pwd >> /usr/ports >> >> odin$ make search key=texmacs >> Please install portslist >> pkg_add portslist >> *** Error 1 in /usr/ports (Makefile:80 '/usr/local/share/ports-INDEX': @exit >> 1) >> >> odin$ doas pkg_add portslist >> portslist-6.8: ok >> odin$ make search key=texmacs >> Please install portslist > > portslist does not bring back "make search key=" Yes it does, as long as you aren't mixing -current ports and release packages. (Sometimes you get lucky and such a mixture works, but don't count on it).
Re: netstat *:* udp sockets
On 08:25 Mon 17 Dec, Claudio Jeker wrote: > On Sun, Dec 16, 2018 at 05:09:06PM -0500, Ted Unangst wrote: > > Claudio Jeker wrote: > > > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote: > > > > Philip Guenther wrote: > > > > > And, perhaps more directly, how would I block this in pf.conf? > > > > > > > > > > > > > > > > Excellent choice, blocking dhclient from receiving the leases that it > > > > > requests. > > > > > "What problem are you trying to solve?" > > > > > > > > Well, this may be something of a lost cause, but I would prefer that > > > > chrome > > > > not listen for stuff I don't understand. It listens on port 5353 as > > > > well, for > > > > mDNS, and I can block that easily enough. It's the socket without a port > > > > that's giving me trouble. > > > > > > But a socket without a port is not listening on anything. It will not get > > > any packets. It does not need to be filtered. This is how UDP works, it is > > > a connectionless protocol. > > > > ok, thank you, I was confused because they show up in netstat -ln too. I > > guess > > that's just historic how it is behavior. > > I guess we should change that. Problem is that UDP does not support > listen(2) and so there is no listening state. Should netstat exclude all > of UDP when using -l or what should it show? Only sockets that are bound > but not connected (local port != 0 but remote addr/port = 0)? A listening socket is a socket that can "accept" new "connections" -- it's possible to send data to it from some new host (e.g. via sendto). So local_port != 0 remote_addr == NULL is perfectly fine IMO.
