Re: {r,s}mkx entries in terminfo db missing
I solved it (for the moment) by patching st, as patching st is something you most likely do anyways. The patch, including a description, can be found on the suckless wiki [1]. But this solution is a bit tricky, becuase you will have problems in the moment you connect to another system where the definition of st-git is not present. Maybe the best solution can be update the definition of st in OpenBSD. Regards, -- Roberto E. Vargas Caballero
Re: upgrades no longer allow ftp for sets
On 2014 Mar 25 (Tue) at 20:38:08 -0500 (-0500), Shawn K. Quinn wrote: :On Tue, Mar 25, 2014, at 08:10 PM, n...@leviacomm.net wrote: : Thanks and I understand the reasoning. The current ftp server won't be : able to do http and use of siteXX files prevents using an external : source. Will nfs be supported or am I going to need more hardware? : :What is preventing you from using, say, a USB thumb drive as the install :media? Also note you can install from multiple sources (http for :everything else, then a local disk for the siteXX files). : I am upgrading hundreds of boxes a day That is an *excellent* reason to not use usb thumb drives. Want another reason? Remote machines with serial console -- Rudin's Law: If there is a wrong way to do something, most people will do it every time.
Re: Building libav/ffmpeg x264 on 5.4
Good morning,
Well, holy crap. I'm feeling a bit stupid now, but I am still very new to
OpenBSD. I
wasn't aware of all the limits the system would impose on a regular user. It is
pretty
nice though, from a security and stability perspective.
So, to fix this, I did chpass myuser as root and added my user to the
staff login
class. Then I edited /etc/login.conf to increase the default amount of memory
that a
user belonging to the staff class can allocate. From 512MB to 2048MB. The
process I am
running might require something just shy of or slightly above 1GB, so yeah. I
was just
too lazy to create my own class, so staff will have to do.
And, well. My build works now. That was exactly why I needed some input from
experienced
people, because I just don't have an idea of how to REALLY work with OpenBSD
(yet).
So thanks for that!
As for the other posts: Installing ffmpeg as a package can be done, but x264
would refuse
to link against it. Maybe the newest x264 source code is just too new or
something? Or
some headers are missing? No idea. So I went back to building libav myself and
link x264
against that.
Also it's nice to hear that 5.5 will come with a more modern assembler, I have
played
around with LLVM/Clang before, didn't know Clang included its own assembler
too. Looking
forward to the next release, and thanks again! :)
Best,
Michael
On 03/25/2014 04:32 PM, Andrei Vrincianu wrote:
Hi Michael,
Maybe it's not because of this, but did you try raising the data segment
size limit for your user? ulimit -a should help.
Best,
Andrei Vrincianu
On Tue, Mar 25, 2014 at 3:35 PM, Michael Lackner
michael.lack...@unileoben.ac.at wrote:
Greetings!
This is my first question here, please be gentle! ;)
So, as the subject line says, I am currently attempting to compile,
install and run
either the libav or ffmpeg media codec suite and then x264 on OpenBSD 5.4,
where x264
is then linked against either libav or ffmpeg. All of this on the
x86_64/AMD64
architecture. x264 itself is a H.264/AVC video trans-/encoder.
So far so good.
The first big problem was the lack of a new enough GNU assembler
(as/gas), as x264
features SSSE3 inline assembly, that gas from binutils 2.15 cannot build.
So I went ahead
and compiled myself my own gas from binutils 2.24, which supposedly worked
fine.
But the real bummer is what follows, and this error even shows up, if I
disable all
assembly optimizations in libav/ffmpeg as well as x264 (then it even
compiles on a stock
5.4 without my new gas 2.24, but won't run).
So, I start my video transcoding, and I get this (leaving out the [info]
lines):
x264 [error]: malloc of size 8856384 failed
x264 [error]: x264_encoder_encode failed
aborted at input frame 13, output frame 0
I suspect x264 and not the libav/ffmpeg it was linked against, because 13
input frames
were seemingly decoded by libav/ffmpeg, but not a single output frame was
encoded by x264.
Using older versions of x264/libav (up to 1 year old I tried) results in
the same problem,
only the malloc() size number is different. Like 31736 instead of the
8856384 above.
Just in case you'd wanna know, this is a sample command line like the one
I called:
x264 --preset veryslow --tune film --b-adapt 2 --b-pyramid normal -r 3 -f
-2:0 --bitrate 1 --aq-mode 1 -p 1 --slow-firstpass --stats
framestats.stats -t 2 --no-fast-pskip --cqm flat input.264 -o
pass1output.264
I tried compiling this with and without assembly, and with both GCC 4.2.1
as well as GCC
4.8.1. The error is always the same.
To learn more, I thought I'd take a look at the x264 port of OpenBSD 5.4,
but found this
in its Makefile, disabling all linking against both libav and ffmpeg as
well as disabling
all assembly (likely due to the binutils/gas issue):
CONFIGURE_ARGS+=--disable-asm \
--disable-ffms \
--disable-gpac \
--disable-lavf \
--disable-swscale \
--enable-static \
--prefix=${PREFIX}
The ffms thing disables linking against ffmpeg, the lavf+swscale stuff
disables linking
against libav. asm is self-explanatory.
So the x264 port (as well as the precompiled package) are completely
crippled. Not only is
the assembly missing, costing tons of performance, but you can't even feed
anything but
raw video to it! What I need is the capability to feed stuff like
H.264/AVC, MPEG2, VC-1
videostreams etc. to x264, so I need libav or ffmpeg.
Now, the main issue is the malloc() failure here. My home-brewn gas
shouldn't be the
problem, because it happens even when compiling from pure C/C++.
My assumption would be, that maybe OpenBSDs libc implementation of
malloc() behaves in
ways that x264 can't handle properly?! I've tried looking at the x264
source coude, but
this stuff is just way beyond me, I don't understand any of the code
really.
I have so far managed to do this on NetBSD, FreeBSD/PC-BSD, MidnightBSD,
Dragonfly BSD,
OpenSolaris, Linux, Windows (CygWin and MinGW/MSYS), MacOS X and even
Haiku OS with
varying degrees of modifications to the build
Re: DTMF tones over IP
On Mar 25 15:24:03, byronklipp...@ml1.net wrote: Is there a way to generate DTMF tones using the tools in base? I am trying to open a live audio path over IP from one node to another. The audio path is fed into a controlling device which interfaces with a VHF radio. In order to key-up the radio, the controlling device needs to see a DTMF code (1 to key, 0 to unkey). Any audio sent to the device between keying and unkeying, is sent to the radio and over air. I'm guessing an ssh-tunnel will server as the path, just not sure which framework can be used to record and play audio, See aucat(1) for general audio work. It also works nicely over ssh (see http://marc.info/?l=openbsd-miscm=136500465604928w=3 for inspiration). let alone generate DTMF. I would use the SoX package for this ... On Mar 25 17:06:50, fritz.k...@gmail.com wrote: play -n synth 0.5 sine 697 sine 1209 channels 1 play -n synth 0.5 sine 941 sine 1336 channels 1 ... but only slightly differently: play -c 1 -n synth 0.5 sine 697 sine 1209 gain -6 play -c 1 -n synth 0.5 sine 941 sine 1336 gain -6
Thinkpad T60 awake from sleep problems
Hi, I am running stock generic kernel 5.4 on a Thinkpad T60 (model with ATI graphics). When I hit the sleep button (Fn-F4) the laptop seems to correctly go to sleep until the traditional Moon LED lights up. However, when i try to power it up again, I hear the fan spinning up, the life LED shows the machine is up, but the Moon led blinks fast, the screen remains black and I cannot power down the machine anymore. I need to press the power button for 5 secs and force it down. Riccardo OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Genuine Intel(R) CPU T2500 @ 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF real mem = 3219517440 (3070MB) avail mem = 3155464192 (3009MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/01/10, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 79ETE6WW (2.26 ) date 04/01/2010 bios0: LENOVO 2007WRU acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU T2500 @ 2.00GHz (GenuineIntel 686-class) 2 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 92P1137 serial 121 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 0xe/0x1! cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2000, 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: apic 1 int 16 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility X1400 rev 0x00 radeondrm0 at vga1: apic 1 int 16 drm0 at radeondrm0 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices AD1981HD audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20 pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 Intel 82573L rev 0x00: msi, address 00:15:58:2e:43:6c ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 1 int 21 pci3 at ppb2 bus 3 wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, address 00:13:02:9a:52:1b ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 22 pci4 at ppb3 bus 4 ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 1 int 23 pci5 at ppb4 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb5 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci6 at ppb5 bus 21 cbb0 at pci6 dev 0 function 0 TI PCI1510 CardBus rev 0x00: apic 1 int 16 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 ichpcib0 at pci0 dev 31 function 0 Intel 82801GBM LPC rev 0x02: PM disabled pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x02: DMA, channel 0
Re: {r,s}mkx entries in terminfo db missing
Roberto E. Vargas Caballero schrieb am 26.03.2014 07:47: I solved it (for the moment) by patching st, as patching st is something you most likely do anyways. The patch, including a description, can be found on the suckless wiki [1]. But this solution is a bit tricky, becuase you will have problems in the moment you connect to another system where the definition of st-git is not present. Maybe the best solution can be update the definition of st in OpenBSD. Regards, -- Roberto E. Vargas Caballero While this is true, you'll most likely always have problems using st from git, because on most operating systems, only the latest stable st (version 0.4.1) is available as a package, and there have been massive changes to the terminfo file since then. Problems with a new st and outdated terminfo information were the motivation for this thread, so letting users know that the terminfo is missing on remote machines is IMHO a better solution than to let them think everything is fine. For now, it would be good to update the terminfo to 0.4.1 (upstream in ncurses and in openbsd), so that at least the version from ports can work flawlessly. I will set up a diff. Regards, Nils
Re: upgrades no longer allow ftp for sets
One other reason is that our ftp *client* is a pile of crud. Almost anyone who approaches it runs away screaming (or becomes berserk, grabs an axe, and starts cutting madly at the rest of the tree)
Re: Openbsd Routing/NAT Internet Issues
Hi, Can see you are allowing packets 'out' of your internal interfaces, but what about packets getting into your internal interfaces? pass quick on ath0/rl0 keep state Also, if you have a private IP address on your modem (it will be doing NAT), and you are trying to NAT on your OpenBSD box, you are double NATing which is bad.. Either put the modem into bridged mode to allow placing the ISPs public IP addres onto the external interface of the OpenBSD box (recomended), or don't NAT on the OpenBSD box. Cheers, A On Wed 26 Mar 2014 03:28:59 GMT, Wong Peter wrote: Hello to all, I had try to set up openbsd as home router but eventually it fail to function properly. External Interface (vr0) 192.168.1.2 255.255.255.0 none Internal Interface (rl0) 172.16.10.1 255.255.255.0 none Wireless Interface (ath0) 192.168.5.1 255.255.255.0 none External interface connects to a modem with ip address of 192.168.1.254. *Routing Table* (route show | more) Destination Gateway Flags Interface default 175.13.8.127.254 UGS tun0 175.130.127.254 175.135.116.213 (PPPOE IP address) UH tun0 loopback loopback UGRS lo0 loopback loopback UH lo0 172.16.10/24 link#2 UC rl0 172.16.10.3 inet6 UHLC rl0 192.168.1/24 link#1 UC vr0 192.168.5/24 link#3 UC ath0 My wireless interface light is keep on blinking rather stay on stable mode. *Packet Filter Rules* (pfcrt -sr) nat on vr0 from !(vr0) to any - (vr0) round-robin scrub on vr0 all no-df fragment reassemble scrub on vr0 all reassemble tcp block drop in log on vr0 all pass out quick on ath0/rl0 keep state. Problem: I can ping Google DNS(8.8.8.8) from openbsd machine. or browsing internet. I cannot ping Google DNS(8.8.8.8) from LAN PC. I can ping my external modem(192.168.1.254) which return echo reply. I have no idea why ping the modem does reply but ping external network with no reply. Please help.
Re: Anyone tried new PC-Engines apu1c board yet?
On 26.03.2014 00:51, Theo de Raadt wrote: I've been thinking about upgrading my Alix 2d3 board to the new apu1c/apu1c4 (http://www.pcengines.ch/apu1c.htm) - I think there was some availability a few weeks ago but now the site says they are out of stock until April 5, 2014 (http://www.pcengines.ch/order1.php?c=4). Anyway, I was wondering if anyone has had a chance to test one of these boards yet with OpenBSD? If so, what are your thoughts? Any issues with the Realtek RTL8111E? Some of these machines are in the group. They are nice machines.. we've been able to play with them using some workarounds. The BIOS is not ready yet, it has a variety of problems. We are working with PC-Engines to get them fixed. It isn't just OpenBSD that is affected. I don't think it will take long. A new BIOS can be flashed, but the process is a little bit annoying in this state (once OpenBSD works natively, it will be easier to load the tools and do it). So perhaps wait just a little while longer, so that you can get a machine with the right BIOS. Great, thank you for the info, Theo. I will indeed wait until the BIOS issues are sorted out. -- Chess Griffin
Re: upgrades no longer allow ftp for sets
On 2014-03-26, n...@leviacomm.net n...@leviacomm.net wrote: I am upgrading hundreds of boxes a day with only have serial access to them. Installing from an external source would bring any server I use to its knees (I end up using 4-5 Gbps of bandwidth during upgrades. Sounds like an excellent reason to setup a new infrastructure with HTTP server and using the new autoinstall/autoupgrade functionality in the installer. I assume packages will still be able to grabbed over ftp, although I suspect I should be planning for that to go away too at some point. I don't know, but I wouldn't want to use ftp to update packages anyway, it goes so much faster over HTTP.
Re: Openbsd Routing/NAT Internet Issues
On 26-03-2014 03:28, Wong Peter wrote: Problem: I can ping Google DNS(8.8.8.8) from openbsd machine. or browsing internet. I cannot ping Google DNS(8.8.8.8) from LAN PC. I can ping my external modem(192.168.1.254) which return echo reply. I have no idea why ping the modem does reply but ping external network with no reply. Please help. Are you forwarding packets between interfaces? $ sysctl net.inet.ip.forwarding
Re: Openbsd Routing/NAT Internet Issues
On Wed, Mar 26, 2014 at 4:28 AM, Wong Peter peterap...@gmail.com wrote: Hi *Routing Table* (route show | more) Destination Gateway Flags Interface default 175.13.8.127.254 UGS tun0 175.130.127.254 175.135.116.213 (PPPOE IP address) UH tun0 should'n be your default gateway your external modem, 192.168.1.254? What is this pppoe?
Re: Openbsd Routing/NAT Internet Issues
On Wed, Mar 26, 2014 at 12:10 PM, Zé Loff zel...@zeloff.org wrote: Are you forwarding packets between interfaces? $ sysctl net.inet.ip.forwarding modem is responding (to internal LAN, I suppose), so it must enabled, -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/
unlink utility
Hello!
For some reason POSIX X/Open Systems Interfaces option requires 'unlink'
utility to be present in operating system. Sure, it does nothing that
'rm' doesn't already do, but given that 'unlink' is already used in some
scripts, I wonder if it would be benefitial for OpenBSD to include such
utility.
FWIW a simple implementation follows.
unlink.c
/*
* Copyright (c) 2014 Dmitrij D. Czarkoff czark...@gmail.com
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHORS DISCLAIM ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include errno.h
#include locale.h
#include stdio.h
#include stdlib.h
#include unistd.h
extern char *__progname;
void usage(void);
int
main(int argc, char **argv)
{
setlocale(LC_ALL, );
if (argc != 2) {
usage();
} else if (unlink(*(argv+1))) {
perror(unlink);
return errno;
}
return 0;
}
void
usage(void)
{
(void)fprintf(stderr, usage: %s file\n, __progname);
exit(1);
}
unlink.1
.\
.\ Copyright (c) 2014 Dmitrij D. Czarkoff czark...@gmail.com
.\
.\ Permission to use, copy, modify, and distribute this software for any
.\ purpose with or without fee is hereby granted, provided that the above
.\ copyright notice and this permission notice appear in all copies.
.\
.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\
.Dd $Mdocdate: March 26 2014 $
.Dt UNLINK 1
.Os
.Sh NAME
.Nm unlink
.Nd call the
.Xr unlink 2
function
.Sh SYNOPSIS
.Nm unlink
.Ar file
.Sh DESCRIPTION
The
.Nm
utility calls
.Xr unlink 2
function to remove a
.Ar file
specified on the command line.
.Pp
A user may need appropriate privileges to invoke the
.Nm
utility.
.Sh EXIT STATUS
.Ex -std unlink
.Sh SEE ALSO
.Xr link 1,
.Xr rm 1 ,
.Xr unlink 2
.Sh STANDARDS
The
.Nm
utility is compliant with the
.St -p1003.1-2008
specification.
.Sh HISTORY
The
.Nm
utility first appeared in
.Ox 5.6 .
--
Dmitrij D. Czarkoff
Re: Openbsd Routing/NAT Internet Issues
On 26-03-2014 11:13, Cristiano Deana wrote: On Wed, Mar 26, 2014 at 4:28 AM, Wong Peter peterap...@gmail.com wrote: Hi *Routing Table* (route show | more) Destination Gateway Flags Interface default 175.13.8.127.254 UGS tun0 175.130.127.254 175.135.116.213 (PPPOE IP address) UH tun0 should'n be your default gateway your external modem, 192.168.1.254? What is this pppoe? No, you can have an address on the ethernet interface (vr0 in his case) and then have PPPoE over that interface. I have (approximately) the same configuration on my DSL modem, which is on bridge mode but still listens on 192.168.1.254. The default gateway is the pppoe0 link, but there's a route to 192.168.1/24 on the ethernet interface which I use to access the modem's web UI.
Re: Openbsd Routing/NAT Internet Issues
Hi, Le 26/03/2014 12:13, Cristiano Deana a écrit : On Wed, Mar 26, 2014 at 4:28 AM, Wong Peter peterap...@gmail.com wrote: Hi *Routing Table* (route show | more) Destination Gateway Flags Interface default 175.13.8.127.254 UGS tun0 175.130.127.254 175.135.116.213 (PPPOE IP address) UH tun0 should'n be your default gateway your external modem, 192.168.1.254? What is this pppoe? I agree this, In this case, I think the NAT rule should be : nat on tun0 from !(tun0) to any - (tun0) (also seems to be old syntax) Regards, Christophe.
Re: unlink utility
Hello,
without commenting on the need for the utility itself, the code you have
provided does not respect the coding style of OpenBSD, and your main
function shouldn't be returning errno
Gilles
On 03/26/14 12:19, Dmitrij D. Czarkoff wrote:
Hello!
For some reason POSIX X/Open Systems Interfaces option requires 'unlink'
utility to be present in operating system. Sure, it does nothing that
'rm' doesn't already do, but given that 'unlink' is already used in some
scripts, I wonder if it would be benefitial for OpenBSD to include such
utility.
FWIW a simple implementation follows.
unlink.c
/*
* Copyright (c) 2014 Dmitrij D. Czarkoff czark...@gmail.com
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHORS DISCLAIM ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include errno.h
#include locale.h
#include stdio.h
#include stdlib.h
#include unistd.h
extern char *__progname;
void usage(void);
int
main(int argc, char **argv)
{
setlocale(LC_ALL, );
if (argc != 2) {
usage();
} else if (unlink(*(argv+1))) {
perror(unlink);
return errno;
}
return 0;
}
void
usage(void)
{
(void)fprintf(stderr, usage: %s file\n, __progname);
exit(1);
}
unlink.1
.\
.\ Copyright (c) 2014 Dmitrij D. Czarkoff czark...@gmail.com
.\
.\ Permission to use, copy, modify, and distribute this software for any
.\ purpose with or without fee is hereby granted, provided that the above
.\ copyright notice and this permission notice appear in all copies.
.\
.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\
.Dd $Mdocdate: March 26 2014 $
.Dt UNLINK 1
.Os
.Sh NAME
.Nm unlink
.Nd call the
.Xr unlink 2
function
.Sh SYNOPSIS
.Nm unlink
.Ar file
.Sh DESCRIPTION
The
.Nm
utility calls
.Xr unlink 2
function to remove a
.Ar file
specified on the command line.
.Pp
A user may need appropriate privileges to invoke the
.Nm
utility.
.Sh EXIT STATUS
.Ex -std unlink
.Sh SEE ALSO
.Xr link 1,
.Xr rm 1 ,
.Xr unlink 2
.Sh STANDARDS
The
.Nm
utility is compliant with the
.St -p1003.1-2008
specification.
.Sh HISTORY
The
.Nm
utility first appeared in
.Ox 5.6 .
Re: {r,s}mkx entries in terminfo db missing
If you get it updated in ncurses and drop me a note privately I will update termtypes.master. On Wed, Mar 26, 2014 at 10:15:14AM +0100, Nils R wrote: Roberto E. Vargas Caballero schrieb am 26.03.2014 07:47: I solved it (for the moment) by patching st, as patching st is something you most likely do anyways. The patch, including a description, can be found on the suckless wiki [1]. But this solution is a bit tricky, becuase you will have problems in the moment you connect to another system where the definition of st-git is not present. Maybe the best solution can be update the definition of st in OpenBSD. Regards, -- Roberto E. Vargas Caballero While this is true, you'll most likely always have problems using st from git, because on most operating systems, only the latest stable st (version 0.4.1) is available as a package, and there have been massive changes to the terminfo file since then. Problems with a new st and outdated terminfo information were the motivation for this thread, so letting users know that the terminfo is missing on remote machines is IMHO a better solution than to let them think everything is fine. For now, it would be good to update the terminfo to 0.4.1 (upstream in ncurses and in openbsd), so that at least the version from ports can work flawlessly. I will set up a diff. Regards, Nils
Re: upgrades no longer allow ftp for sets
Em 25-03-2014 23:27, n...@leviacomm.net escreveu: I am upgrading hundreds of boxes a day with only have serial access to them. Installing from an external source would bring any server I use to its knees (I end up using 4-5 Gbps of bandwidth during upgrades. I assume packages will still be able to grabbed over ftp, although I suspect I should be planning for that to go away too at some point. Original Message Subject: Re: upgrades no longer allow ftp for sets From: Shawn K. Quinn skqu...@rushpost.com Date: Tue, March 25, 2014 6:38 pm To: misc@openbsd.org On Tue, Mar 25, 2014, at 08:10 PM, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? What is preventing you from using, say, a USB thumb drive as the install media? Also note you can install from multiple sources (http for everything else, then a local disk for the siteXX files). Why don't you create your own internal mirror? Or your own external mirror if you have the bandwidth/server available? I did had a complete mirror for internal installs with siteXX and I didn't used ftp. Please, help us purge this protocol from the internet. If your siteXX has sensible information you can use ssl with authentication. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: dhclient
On Tue, Mar 25, 2014 at 4:02 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: well openBSD is so neat it provides a nice call: http://www.openbsd.org/cgi-bin/man.cgi?query=pidfileapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html but i failed to patch :'( this make the dhclient quit instead of going background, the fact there is two process may also explain why there is no pidfile. One is root he other dropped privilege, all of this is just giving me a headache at the moment. pidfile() is a dangerous subsystem. The files stay around long after the process has died. There is no interlock. If you signal a process lists in a pidfile, who knows what you are sending a signal to. Since the signals are often termination related, this can have dangerous effects. We don't add more pidfile use, we actually remove them where we can. This mechanism has applicability in some situations, but in the big picture it is sloppy practice. Ok. Listing process takes also times, and deleting the listed PID may also end in deleting another process in a race condition case. Or is there some kind of smart lock inside pkill ? Because pidfile subsystems exists, would it be possible to let the kernel create and delete a read_only pidfile when forking/cleaning the process ? -- - () ascii ribbon campaign - against html e-mail /\
Re: 5.4 hanging when used as hostap
On Tue, 2014-03-25 at 12:46 +0100, Stefan Sperling wrote: The diff below backs out my changes for ral from 5.3-5.4. Can you test this? I doubt it will have any effect but if it does I'd very much like to know about it. thanks for the suggestion! i may not have a chance till the weekend, but i'll try applying the diff and see how it goes. It is possible that your power supply is having issues. With my net5501 I was seeing hard lockups until I upgraded to a stronger power supply (same voltage, more ampere). The default power supply couldn't power the board, a hard disk, and a wireless minipci card (also a ral rt2661 in my case). You seem to be using a hard disk instead of a CF card, correct? If you like I can look up the exact specs of the power supply I'm using tonight. yes, my net5501 is running off a hard disk. i'm using munin to graph the voltage sensors and nothing jumps out at me (though i don't know that it would). if you could provide your specs that'd be great. it looks like my power supply is an SBU40C-120; the info sticker says 12V 3.34A 40W max. from what i can tell that looks like the highest ampere psu that soekris has available online. i don't have a great feel for amps/watts/volts, but i believe it should power this setup (board says 6W; hd, 1.7 W; wifi 350mA =~ 4W (?)). if the current one does look like it should be sufficient i could order a replacement or (if there's a suggested model) try picking up a different one. thanks again... andy -- andy and...@diatribes.org
Re: upgrades no longer allow ftp for sets
On 03/25/14 21:09, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? I'm not understanding something here, and I think most of the rest of us are missing it, as well. You can pick up hardware capable of serving http to all your machines for upgrade off my curb today. Really, it takes almost nothing to build a very capable web server for static content. Since you are probably talking about only one or two platforms, a small SSD can hold all the files and packages, put into a seven year old computer with SATA interface, and ta-da, you got a $100 (or way less) http server that will absolutely kick ***. I find it unlikely your existing FTP server can't have a web server added and pointed at the same directory your FTP is being served from now, unless it is some bizarre little appliance thing, in which case, you would really benefit from an upgrade, performance-wise. So...is there a real problem in your environment that makes FTP more desirable? If so, I'm sure a lot of us would like to be educated on this...or is it just a reluctance to change? Nick.
Re: unlink utility
On Wed, Mar 26, 2014 at 12:19, Dmitrij D. Czarkoff wrote: For some reason POSIX X/Open Systems Interfaces option requires 'unlink' utility to be present in operating system. Sure, it does nothing that With no rationale given. :( 'rm' doesn't already do, but given that 'unlink' is already used in some scripts, I wonder if it would be benefitial for OpenBSD to include such utility. Sometimes I think refusing to implement stupid standards is the only way to fight back.
Re: unlink utility
Gilles Chehade said:
without commenting on the need for the utility itself, the code you have
provided does not respect the coding style of OpenBSD, and your main
function shouldn't be returning errno
Sorry, I was not paying enough attention to style.
What about this one:
unlink.c
/*
* Copyright (c) 2014 Dmitrij D. Czarkoff czark...@gmail.com
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include errno.h
#include locale.h
#include stdio.h
#include stdlib.h
#include unistd.h
extern char *__progname;
static void usage(void);
int
main(int argc, char **argv)
{
setlocale(LC_ALL, );
if (argc != 2)
usage();
else if (unlink(*(argv + 1))) {
perror(__progname);
return (1);
}
return (0);
}
static void
usage(void)
{
(void)fprintf(stderr, usage: %s file\n, __progname);
exit(1);
}
--
Dmitrij D. Czarkoff
Re: unlink utility
Le Wed, 26 Mar 2014 12:19:25 +0100,
Dmitrij D. Czarkoff czark...@gmail.com a écrit :
Hello,
For some reason POSIX X/Open Systems Interfaces option requires
'unlink' utility to be present in operating system. Sure, it does
nothing that 'rm' doesn't already do, but given that 'unlink' is
already used in some scripts, I wonder if it would be benefitial for
OpenBSD to include such utility.
FWIW a simple implementation follows.
On FreeBSD /bin/unlink is a link to /bin/rm
/*
* Test for the special case where the utility is called as
* unlink, for which the functionality provided is greatly
* simplified.
*/
if ((p = strrchr(argv[0], '/')) == NULL)
p = argv[0];
else
++p;
if (strcmp(p, unlink) == 0) {
while (getopt(argc, argv, ) != -1)
usage();
argc -= optind;
argv += optind;
if (argc != 1)
usage();
rm_file(argv[0]);
exit(eval);
}
} else if (unlink(*(argv+1))) {
Hmm the code in rm does more than a simple unlink(2).
Regards,
Re: upgrades no longer allow ftp for sets
On 2014-03-25 Tue 18:34 PM |, Theo de Raadt wrote: The 5.5 release will support FTP releases, but after that we are disabling FTP and thus pushing people to use HTTP installs. In this day and age, it is somewhat irresponsible for us to put people into a situation where they might install new FTP servers on the internet. We've known it is a dangerous protocol for over 20 years. Use a HTTP server to serve the sets, please. Would these pages summarise it? http://cr.yp.to/ftp/security.html http://tools.ietf.org/html/rfc2577 http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security http://daniel.haxx.se/docs/ftp-vs-http.html
Re: Oerrs on vlan interfaces
Matt Carey [cvstealth2...@yahoo.com] wrote: I'm trying to track down the source of what is causing output errors on vlan interfaces for 2 separate physical systems. ?For example when looking at netstat between 2 different runs the values are always incrementing: # netstat -s -f inet -I vlan800 echo sleep 5 netstat -s -f inet -I vlan800? Name ? ?Mtu ? Network ? ? Address ? ? ? ? ? ? ?Ipkts Ierrs ? ?Opkts Oerrs Colls vlan800 1500 ?Link ? ? ?00:1c:23:e1:cf:48 187689428 ? ? 0 148043392 262767 ? ? 0 This output is mostly unreadable. Maybe the yahoo mailer is the problem. The same behavior is mimicked on both systems as the counters start incrementing when failing over the carp interfaces between the peers. Another oddity that is the physical interfaces show no output errors just input errors: Take a look at /usr/src/sys/net/if_vlan.c, there are three places where it increases if_oerrors. You could try to sprinkle unique printfs next to each if_oerrors++ to see which one is getting triggered. Each one happens for a different reason, parent interface not UP/RUNNING, parent interface doesn't handle its own tagging and if_vlan can't allocate mbuf, etc.
Re: unlink utility
but given that 'unlink' is already used in some scripts I would like to see some proof of that. The way I see it, the ports tree is a large enough ecosystem capable of measuring whether something is in use. So, since it isn't in the ports tree, please show some proof.
Re: unlink utility
Ted Unangst wrote Sometimes I think refusing to implement stupid standards is the only way to fight back. Thank you. For such as this I lurk on this list, not for help with OpenBSD, but for help with everything else. Something OpenBSD does get right. Good Stuff is not made from more of Bad Stuff.
Re: unlink utility
Dmitrij D. Czarkoff czark...@gmail.com writes:
Gilles Chehade said:
without commenting on the need for the utility itself, the code you have
provided does not respect the coding style of OpenBSD, and your main
function shouldn't be returning errno
Sorry, I was not paying enough attention to style.
Not discussing the usefulness of unlink(1), but it's bikeshedding time
here. Sorry. :)
What about this one:
unlink.c
/*
* Copyright (c) 2014 Dmitrij D. Czarkoff czark...@gmail.com
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include errno.h
#include locale.h
#include stdio.h
#include stdlib.h
#include unistd.h
extern char *__progname;
static void usage(void);
int
main(int argc, char **argv)
{
setlocale(LC_ALL, );
if (argc != 2)
usage();
I suggest using getopt() and the usual argc -= optind, argv += optind
dance, for consistency at the source level and to handle --
transparently.
else if (unlink(*(argv + 1))) {
With what I said above, this becomes *argv.
perror(__progname);
return (1);
err() can do this in one line, while giving you a more rich error message:
err(1, unable to delete `%s', *argv);
}
return (0);
}
static void
usage(void)
{
(void)fprintf(stderr, usage: %s file\n, __progname);
Now that we have getprogname(), maybe we could start using it?
exit(1);
}
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: unlink utility
Theo de Raadt dera...@cvs.openbsd.org writes: but given that 'unlink' is already used in some scripts I would like to see some proof of that. The way I see it, the ports tree is a large enough ecosystem capable of measuring whether something is in use. So, since it isn't in the ports tree, please show some proof. The only port that we patch so that it calls rm -f instead of unlink at runtime is sysutils/gitolite. The patch has already been committed upstream. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: unlink utility
Theo de Raadt wrote: but given that 'unlink' is already used in some scripts I would like to see some proof of that. The use that triggered my original mail was in tests for devel/py-dulwich. And I am quite sure I've seen it elsewhere recently, but I have no proof for that. P.S.: Apparently there is another patch to remove 'unlink' in ports - in sysutils/gitolite. Thankfully this appears to come from upstream. -- Dmitrij D. Czarkoff
Re: unlink utility
but given that 'unlink' is already used in some scripts I would like to see some proof of that. The use that triggered my original mail was in tests for devel/py-dulwich. Perhaps you can push upstream to use the better tools? How long before we find clri being used?
Re: upgrades no longer allow ftp for sets
On Wed, Mar 26, 2014 at 10:41, Marc Espie wrote: One other reason is that our ftp *client* is a pile of crud. Almost anyone who approaches it runs away screaming (or becomes berserk, grabs an axe, and starts cutting madly at the rest of the tree) I have seen no evidence of this ever happening.
Re: dhclient
On Mar 26 09:29:16, sven.falem...@gmail.com wrote: Listing process takes also times, pkill doesn't list anything. No really, read the manpage. and deleting the listed PID may also end in deleting another process in a race condition case. Or is there some kind of smart lock inside pkill ? No. Because pidfile subsystems exists, would it be possible to let the kernel create and delete a read_only pidfile when forking/cleaning the process ? Lets save the process table in individual files!
Re: unlink utility
Theo de Raadt wrote: Perhaps you can push upstream to use the better tools? I did, and I always do so. -- Dmitrij D. Czarkoff
unbound patch
Small problem building unbound on -current; fixed with this patch to
prevent doc/unbound-host.1 from being removed on the clean target.
Index: Makefile.bsd-wrapper
===
RCS file: /depot/cvs/openbsd/src/usr.sbin/unbound/Makefile.bsd-wrapper,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile.bsd-wrapper
--- Makefile.bsd-wrapper21 Mar 2014 00:23:15 - 1.8
+++ Makefile.bsd-wrapper26 Mar 2014 16:47:17 -
@@ -91,7 +91,7 @@ install: maninstall
.endfor
BEFOREMAN= ${.OBJDIR}/config.status
-CLEANFILES+= ${MAN} doc/example.conf doc/libunbound.3
+CLEANFILES+= ${MAN:Ndoc/unbound-host.1} doc/example.conf doc/libunbound.3
clean cleandir:
-@if [ -e Makefile ]; then ${MAKE} realclean; fi
Thanks,
Bill
--
==
William Karh Now look what you made me do.
wk...@yahoo.com -- Ike Turner
Re: dhclient
On Wed, Mar 26, 2014 at 1:55 PM, Jan Stary h...@stare.cz wrote: On Mar 26 09:29:16, sven.falem...@gmail.com wrote: Listing process takes also times, pkill doesn't list anything. No really, read the manpage. and deleting the listed PID may also end in deleting another process in a race condition case. Or is there some kind of smart lock inside pkill ? No. Because pidfile subsystems exists, would it be possible to let the kernel create and delete a read_only pidfile when forking/cleaning the process ? Lets save the process table in individual files! lets talk about /proc :p -- - () ascii ribbon campaign - against html e-mail /\
Re: upgrades no longer allow ftp for sets
On 26 March 2014 13:46, Ted Unangst t...@tedunangst.com wrote: On Wed, Mar 26, 2014 at 10:41, Marc Espie wrote: One other reason is that our ftp *client* is a pile of crud. Almost anyone who approaches it runs away screaming (or becomes berserk, grabs an axe, and starts cutting madly at the rest of the tree) I have seen no evidence of this ever happening. The first thing and last thing axed is always the log. :-) Ken
Re: dhclient
On 2014-03-26 13:31, sven falempin wrote: On Wed, Mar 26, 2014 at 1:55 PM, Jan Stary h...@stare.cz wrote: On Mar 26 09:29:16, sven.falem...@gmail.com [1]wrote: Listing process takes also times, pkill doesn't list anything. No really, read the manpage. and deleting the listed PID may also end in deleting another process in a race condition case. Or is there some kind of smart lock inside pkill ? No. lets talk about /proc :p Quoting from http://en.wikipedia.org/wiki/Everything_is_a_file, However, this is typically not considered a fast or portable approach and should be avoided in most code. I personally don't have a problem with, say, /proc being the canonical source of process data instead of whatever ps(1) calls, but that takes us out of the traditional realm of UNIX and into Plan9 territory. Also note the existence of /dev/mem and /dev/kmem... technically you could therefore say that *everything* is accessible through a file :-). Peeking and pokeing individual bytes in memory has long since been relegated to device drivers because it's a PITA. Using pkill(1) correctly should be more efficient than opening a file, reading its contents, then passing those as an argument to kill(1). Of interest, it appears that to use pkill(1) to signal dhclient(8), in the case where you could have multiple dhclient(8) instances running, you must use the -f flag to pkill and match dhclient: ifname, or you'll signal every dhclient instance on the system. (Yes, I have legitimate cases where I have dhclient running on two or more interfaces.) The privileged process of dhclient does not appear to share the same process group id as the other two processes, and I can't see any way of linking them through PPIDs, process groups, tty groups, or anything else like that. I'd like to know if I'm missing something here... -Adam Links: -- [1] mailto:sven.falem...@gmail.com
Re: dhclient
Using pkill(1) correctly should be more efficient than opening a file, reading its contents, then passing those as an argument to kill(1). None of the mechanisms removes the race. However, of all the mechanisms, pidfiles are the worst. They even persist over reboot.
Re: unbound patch
I have a different fix committed upstream which I'll pull across.
But in order to have hit this you're doing a build in-tree without an
obj directory which is not recommended.
On 2014-03-26, wk...@yahoo.com wk...@yahoo.com wrote:
Small problem building unbound on -current; fixed with this patch to
prevent doc/unbound-host.1 from being removed on the clean target.
Index: Makefile.bsd-wrapper
===
RCS file: /depot/cvs/openbsd/src/usr.sbin/unbound/Makefile.bsd-wrapper,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile.bsd-wrapper
--- Makefile.bsd-wrapper 21 Mar 2014 00:23:15 - 1.8
+++ Makefile.bsd-wrapper 26 Mar 2014 16:47:17 -
@@ -91,7 +91,7 @@ install: maninstall
.endfor
BEFOREMAN= ${.OBJDIR}/config.status
-CLEANFILES+= ${MAN} doc/example.conf doc/libunbound.3
+CLEANFILES+= ${MAN:Ndoc/unbound-host.1} doc/example.conf doc/libunbound.3
clean cleandir:
-@if [ -e Makefile ]; then ${MAKE} realclean; fi
Thanks,
Bill
Re: upgrades no longer allow ftp for sets
On 2014-03-26, Giancarlo Razzolini grazzol...@gmail.com wrote: If your siteXX has sensible information you can use ssl with authentication. The installer doesn't include openssl.
Re: upgrades no longer allow ftp for sets
On 2014-03-26, Giancarlo Razzolini grazzol...@gmail.com wrote: If your siteXX has sensible information you can use ssl with authentication. The installer doesn't include openssl. Funny, Stuart. My processs is to always look at the size of a statically linked binary to make a guess as to whether it could go onto the installer. At the very least, it should fit. (Whether it belongs there is a different question) For this check, the vax is convenient. Binaries are still static. They are actually smaller than they might be on other architectures, so let's compare: textdatabss dec hex 1406523 42740 41692 1490955 16c00b Wow. Only a small part of that is libc code that might be shared by other stuff on the instbin binary which makes the install media work. Whereas the amd64 instbin binary, which contains EVERYTHING you need to install is, today: textdatabss dec hex 1276644 35040 652568 1964252 1df8dc Good luck making it fit.
Re: upgrades no longer allow ftp for sets
Em 26-03-2014 16:48, Stuart Henderson escreveu: On 2014-03-26, Giancarlo Razzolini grazzol...@gmail.com wrote: If your siteXX has sensible information you can use ssl with authentication. The installer doesn't include openssl. I forgot this. I'm so used to ssl webservers, that I forget that the bsd.rd kernel has it's limitations, as all installers have. But I had in the past a complete http mirror of openbsd for amd64 with packages and everything and my own siteXX. It simplified a lot the installation process. And now with the complete automation of the install that has been recently developed, things would be even simpler. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: upgrades no longer allow ftp for sets
Em 26-03-2014 16:59, Theo de Raadt escreveu: On 2014-03-26, Giancarlo Razzolini grazzol...@gmail.com wrote: If your siteXX has sensible information you can use ssl with authentication. The installer doesn't include openssl. Funny, Stuart. My processs is to always look at the size of a statically linked binary to make a guess as to whether it could go onto the installer. At the very least, it should fit. (Whether it belongs there is a different question) For this check, the vax is convenient. Binaries are still static. They are actually smaller than they might be on other architectures, so let's compare: textdatabss dec hex 1406523 42740 41692 1490955 16c00b Wow. Only a small part of that is libc code that might be shared by other stuff on the instbin binary which makes the install media work. Whereas the amd64 instbin binary, which contains EVERYTHING you need to install is, today: textdatabss dec hex 1276644 35040 652568 1964252 1df8dc Good luck making it fit. Theo, I agree with you that the installer must be as small as possible, and still offer a good mix of ways to install the software. With signify, the security of the underlying security of the protocol being used in the installation, becomes irrelevant, as long as you trust the initial key and as long as you are not trying to obfuscate which platform/sets/packages you are installing. Personally I don't do network installs, only as last resort. I prefer using a usb stick. Our OP apparently does not has physical access to the machines so it has to rely on network installs/upgrades, whatever. If he can dedicate a machine for making it's own mirror, it's the best alternative. It would be nice to have openssl in the installer, but it surely isn't much of a problem nowadays. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: upgrades no longer allow ftp for sets
Em 26-03-2014 16:59, Theo de Raadt escreveu: On 2014-03-26, Giancarlo Razzolini grazzol...@gmail.com wrote: If your siteXX has sensible information you can use ssl with authentication. The installer doesn't include openssl. Funny, Stuart. My processs is to always look at the size of a statically linked binary to make a guess as to whether it could go onto the installer. At the very least, it should fit. (Whether it belongs there is a different question) For this check, the vax is convenient. Binaries are still static. They are actually smaller than they might be on other architectures, so let's compare: textdatabss dec hex 1406523 42740 41692 1490955 16c00b Wow. Only a small part of that is libc code that might be shared by other stuff on the instbin binary which makes the install media work. Whereas the amd64 instbin binary, which contains EVERYTHING you need to install is, today: textdatabss dec hex 1276644 35040 652568 1964252 1df8dc Good luck making it fit. Theo, I agree with you that the installer must be as small as possible, and still offer a good mix of ways to install the software. With signify, the security of the underlying security of the protocol being used in the installation, becomes irrelevant, as long as you trust the initial key and as long as you are not trying to obfuscate which platform/sets/packages you are installing. Personally I don't do network installs, only as last resort. I prefer using a usb stick. Our OP apparently does not has physical access to the machines so it has to rely on network installs/upgrades, whatever. If he can dedicate a machine for making it's own mirror, it's the best alternative. It would be nice to have openssl in the installer, but it surely isn't much of a problem nowadays. That's entirely true, but signify only works for the signed base sets. site*.tgz is now a pretty serious outlier. I feel we might have to do a rather large departure from the current model to make that file safe again. I know it is fetched locally, but there is this really twisted dependency on all three files SHA256.sig, SHA256, and index.txt. Regarding safey of site*.gz, placing openssl there is not part of any solution that would work. What are other possible solutions? I do not yet know. One development path may be to remove site*tgz from the main install sequence, and try to handle it in a more special way after base set installs. Even if we have to add an additional question for a while. Then maybe we can develop a better sequence that satisfies the same need. The install scripts are dynamic, something changes in them every release, so this is a natural process.
Re: upgrades no longer allow ftp for sets
Em 26-03-2014 17:18, Theo de Raadt escreveu: Theo, I agree with you that the installer must be as small as possible, and still offer a good mix of ways to install the software. With signify, the security of the underlying security of the protocol being used in the installation, becomes irrelevant, as long as you trust the initial key and as long as you are not trying to obfuscate which platform/sets/packages you are installing. Personally I don't do network installs, only as last resort. I prefer using a usb stick. Our OP apparently does not has physical access to the machines so it has to rely on network installs/upgrades, whatever. If he can dedicate a machine for making it's own mirror, it's the best alternative. It would be nice to have openssl in the installer, but it surely isn't much of a problem nowadays. That's entirely true, but signify only works for the signed base sets. site*.tgz is now a pretty serious outlier. I feel we might have to do a rather large departure from the current model to make that file safe again. I know it is fetched locally, but there is this really twisted dependency on all three files SHA256.sig, SHA256, and index.txt. Regarding safey of site*.gz, placing openssl there is not part of any solution that would work. What are other possible solutions? I do not yet know. One development path may be to remove site*tgz from the main install sequence, and try to handle it in a more special way after base set installs. Even if we have to add an additional question for a while. Then maybe we can develop a better sequence that satisfies the same need. The install scripts are dynamic, something changes in them every release, so this is a natural process. As I mentioned, openssl would only make possible to obfuscate the platform, sets and packages being installed. There a lot of side channels attacks that make possible to tell exactly what you are installing, even if the connection is encrypted. For this reason, I think signify is a much more important change than putting openssl in the installer. The siteXX.tgz should be handled in a different way. Perhaps the way you proposed, of at some point someone can have a different solution. I thought for a while and nothing came up, besides what you already proposed. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: upgrades no longer allow ftp for sets
The FTP server is located on the head units for our dozen+ cabinet SAN/NAS monstrosity from $storage_vendor, getting the software on them to work the way it was shipped is already a huge pain. The plan is to set up a couple of new servers as web servers with a mounted iSCSI volume that points back to the LUN the FTP server was using. The problem being that by the time the hardware request gets processed and the servers installed, I'll be starting on upgrades to 5.7, so nfs will be a temporary measure to allow upgrades to proceed for the time being. Original Message Subject: Re: upgrades no longer allow ftp for sets From: Ted Unangst t...@tedunangst.com Date: Tue, March 25, 2014 9:11 pm To: n...@leviacomm.net Cc: misc@openbsd.org On Tue, Mar 25, 2014 at 18:10, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? nfs is supported, though finding a way to install an http server on your ftp server is still the better option.
Re: upgrades no longer allow ftp for sets
Em 26-03-2014 18:16, n...@leviacomm.net escreveu: The FTP server is located on the head units for our dozen+ cabinet SAN/NAS monstrosity from $storage_vendor, getting the software on them to work the way it was shipped is already a huge pain. It happens. Hardware vendors not shipping decent software? Not news. The plan is to set up a couple of new servers as web servers with a mounted iSCSI volume that points back to the LUN the FTP server was using. The problem being that by the time the hardware request gets processed and the servers installed, I'll be starting on upgrades to 5.7, so nfs will be a temporary measure to allow upgrades to proceed for the time being. You could use some older hardware laying around, if you have it. I don't know if you have many simultaneous installs/upgrades, if not, you can use a very modest hardware for the web server. Good luck. Cheers, Original Message Subject: Re: upgrades no longer allow ftp for sets From: Ted Unangst t...@tedunangst.com Date: Tue, March 25, 2014 9:11 pm To: n...@leviacomm.net Cc: misc@openbsd.org On Tue, Mar 25, 2014 at 18:10, n...@leviacomm.net wrote: Thanks and I understand the reasoning. The current ftp server won't be able to do http and use of siteXX files prevents using an external source. Will nfs be supported or am I going to need more hardware? nfs is supported, though finding a way to install an http server on your ftp server is still the better option. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Seagate ST3250310AS not recognized
I'm trying to install OpenBSD 5.4 on a Dell Vostro 400, it's several years old but not ancient. 4GB RAM, 250GB Seagate ST3250310AS hard drive. The installation goes normally until it tries to find the hard drive and then tells me no hard drive is available. I've wiped the drive (it had ESXi on it before), repartitioned it, unpartitioned it, installed Linux, installed FreeBSD all without problem, but no matter what I do to it, OpenBSD won't see it. I would really like to get this working so any suggestions or guidance is very much appreciated. Thanks, --charlie -- Charles Farinella Systems Administrator Appropriate Solutions, Inc. 603-924-6079
Re: Seagate ST3250310AS not recognized
http://www.openbsd.org/report.html On 26 March 2014 16:59, Charlie Farinella cfarine...@appropriatesolutions.com wrote: I'm trying to install OpenBSD 5.4 on a Dell Vostro 400, it's several years old but not ancient. 4GB RAM, 250GB Seagate ST3250310AS hard drive. The installation goes normally until it tries to find the hard drive and then tells me no hard drive is available. I've wiped the drive (it had ESXi on it before), repartitioned it, unpartitioned it, installed Linux, installed FreeBSD all without problem, but no matter what I do to it, OpenBSD won't see it. I would really like to get this working so any suggestions or guidance is very much appreciated. Thanks, --charlie -- Charles Farinella Systems Administrator Appropriate Solutions, Inc. 603-924-6079
Re: Seagate ST3250310AS not recognized
On Wed, 26 Mar 2014, Charlie Farinella wrote: I'm trying to install OpenBSD 5.4 on a Dell Vostro 400, it's several years old but not ancient. 4GB RAM, 250GB Seagate ST3250310AS hard drive. The installation goes normally until it tries to find the hard drive and then tells me no hard drive is available. Assuming it is recognized in the machine BIOS, .. you mmight have to install a DOS partition table first - it probably still has an ESX partition table, even after wiping. Lee
Re: Seagate ST3250310AS not recognized
Hi Charlie. Bit of a shot in the dark. what sata ports are on the motherboard? can you switch the ports the hard drive is connected to? i have a machine with a similar problem but things work if I connect the hard drive to the sata 2 port instead of the sata 3 port. On Mar 26, 2014, at 4:59 PM, Charlie Farinella cfarine...@appropriatesolutions.com wrote: I'm trying to install OpenBSD 5.4 on a Dell Vostro 400, it's several years old but not ancient. 4GB RAM, 250GB Seagate ST3250310AS hard drive. The installation goes normally until it tries to find the hard drive and then tells me no hard drive is available. I've wiped the drive (it had ESXi on it before), repartitioned it, unpartitioned it, installed Linux, installed FreeBSD all without problem, but no matter what I do to it, OpenBSD won't see it. I would really like to get this working so any suggestions or guidance is very much appreciated. Thanks, --charlie -- Charles Farinella Systems Administrator Appropriate Solutions, Inc. 603-924-6079
Possible to configure -Dunsigned in pkg.conf ?
Hi is it possible to make pkg_add -Dunsigned the default? I have a puppet setup with 5.5 and some custom built packages that are not yet signed. Regards André
Re: Possible to configure -Dunsigned in pkg.conf ?
is it possible to make pkg_add -Dunsigned the default? I have a puppet setup with 5.5 and some custom built packages that are not yet signed. That's not going to happen. For your own private use, you will have to use -Dunsigned. An alternative is start creating your own keys and distribute them to your hosts (/etc/signify/keller-55-pkg.pub), then sign your custom packages. You then get key benefits for both distribution and custom packages.
Re: Possible to configure -Dunsigned in pkg.conf ?
Hi Theo, On 03/27/2014 12:27 AM, Theo de Raadt wrote: is it possible to make pkg_add -Dunsigned the default? I have a puppet setup with 5.5 and some custom built packages that are not yet signed. That's not going to happen. For your own private use, you will have to use -Dunsigned. An alternative is start creating your own keys and distribute them to your hosts (/etc/signify/keller-55-pkg.pub), then sign your custom packages. You then get key benefits for both distribution and custom packages. Well I was just looking for a quick fix. But after reading pkg_sign(1) / signify(1) this turns out to be pretty straightforward... Thanks! André
Re: dhclient
previously on this list Adam Thompson contributed: The flip side is that correct usage of pkill in the face of proctitle alterations is far from obvious. It's never been a problem for me and I thought avoiding pid files was going against the grain. Glad I was doing it right after all. If you can you use the commandline and especially have root acces then this should be very easy. If not, you will simply configure and reboot. Lets hope this doesn't become a problem with the take-up of cgroups and monstrous sized /sbin/init or the rediculously placed /usr/lib/systemd/systemd to cater/replace needlessly monstrously sized linux initscripts. It would be really annoying if ps output became needlessly dynamic but I guess any packages that decides to do that probably won't be worth running anyway. reflecting back on that tiny sentence it seems quite astonishing how much dumb stuff *some* linux devs have managed to strive for in recent years. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___
Re: dhclient
previously on this list Adam Thompson contributed: The flip side is that correct usage of pkill in the face of proctitle alterations is far from obvious. It's never been a problem for me and I thought avoiding pid files was going against the grain. Glad I was doing it right after all. If you can you use the commandline and especially have root acces then this should be very easy. If not, you will simply configure and reboot. Lets hope this doesn't become a problem with the take-up of cgroups and monstrous sized /sbin/init or the rediculously placed /usr/lib/systemd/systemd to cater/replace needlessly monstrously sized linux initscripts. It would be really annoying if ps output became needlessly dynamic but I guess any packages that decides to do that probably won't be worth running anyway. reflecting back on that tiny sentence it seems quite astonishing how much dumb stuff *some* linux devs have managed to strive for in recent years. Pushing complexity into a captured market is a good way to become rich. It worked for Microsoft and Apple, and some new boys are trying the same recipe. On the other hand, it has backfired before too...
Re: Seagate ST3250310AS not recognized
On Wed, Mar 26, 2014, at 05:11 PM, L. V. Lammert wrote: On Wed, 26 Mar 2014, Charlie Farinella wrote: I'm trying to install OpenBSD 5.4 on a Dell Vostro 400, it's several years old but not ancient. 4GB RAM, 250GB Seagate ST3250310AS hard drive. The installation goes normally until it tries to find the hard drive and then tells me no hard drive is available. Assuming it is recognized in the machine BIOS, .. you mmight have to install a DOS partition table first - it probably still has an ESX partition table, even after wiping. On OpenBSD the drive itself should show up in the installer regardless of whatever garbage is in the partition table. For a Windows install, your advice would be spot-on, but OpenBSD's installer is much more intelligent than anything that came out of Redmond, WA, US. -- Shawn K. Quinn skqu...@rushpost.com
Netgear WG311T Atheros Chipset Wireless Problem
Dear all, I had bought a Netgear WG311T Atheros Chipset. The Openbsd kernel(dmesg) shows this card as ath0. Therefore, I try to configure it using /etc/hostname.ath0 with content below: inet 192.168..5.1 255.255.255.0 none media autoselect mediaopt hostap mode 11b chan 6 nwid wsm nwkey This configuration gives me an access point which its LED keeps on blinking and scan from window cannot find the particular nwid as well. I believe there is some problems with it. Please help. Thanks. -- Linux
Re: Seagate ST3250310AS not recognized
On Wed, 26 Mar 2014, Shawn K. Quinn wrote: On OpenBSD the drive itself should show up in the installer regardless of whatever garbage is in the partition table. For a Windows install, your advice would be spot-on, but OpenBSD's installer is much more intelligent than anything that came out of Redmond, WA, US. I would have thought so, but that is the only explanation that makes sense. Anyone ever built on an ESX drive? Lee
Re: Seagate ST3250310AS not recognized
On 03/26/14 16:59, Charlie Farinella wrote: I'm trying to install OpenBSD 5.4 on a Dell Vostro 400, it's several years old but not ancient. 4GB RAM, 250GB Seagate ST3250310AS hard drive. The installation goes normally until it tries to find the hard drive and then tells me no hard drive is available. I've wiped the drive (it had ESXi on it before), repartitioned it, unpartitioned it, installed Linux, installed FreeBSD all without problem, but no matter what I do to it, OpenBSD won't see it. I would really like to get this working so any suggestions or guidance is very much appreciated. First of all, your report sucks. Normally, I try to just ignore bad reports, even when I have a possible W.A.G., but I'm going to try something new... I'm going to say you owe the project a $50 donation if I'm right. And if I'm wrong, you get to buy the 5.5 CDs when they come out and say ha ha! you were WRONG! First of all, if you hooked the drive up properly and it is seen in the bios and all, it isn't a matter of the /drive/ not being recognized, or anything on the drive left over, there's something wrong with the handling of the drive by the interface. All that stuff that goes scrolling by the screen on boot? it's important. it's called the dmesg. Read it, it will tell you why things didn't work. You may well have to interpret things, but somewhere on your dmesg, the chip that is your SATA interface will show up, and right there, it will probably give you a good idea why it isn't acting like a disk interface. And while it looks like gibberish, it's actually fairly readable. My wild guess: you have an ahci interface (this is good), configured in the BIOS for RAID (this is bad). Dell shipped a lot of machines with one disk, with the interface configured in the BIOS as a RAID. This is really just a lame BIOS-assisted OS-based RAID system, like most cheap RAID options, but if the OS doesn't support the RAID idea and it is a multi-booting system, bad things can happen when the BIOS helps you by copying one drive over your other drive, so OpenBSD (and at least some Linux kernels, I've seen) won't touch the drive if it was in the unsupported RAID configuration mode. Nick.
Re: Seagate ST3250310AS not recognized
Everyone who gets useful tech support from this list should feel obligated to donate something to the project. Especially if a Dev took his time to help you; http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/geo/openbsd-developers/files/OpenBSD On Wed, Mar 26, 2014, at 10:52 PM, Nick Holland wrote: On 03/26/14 16:59, Charlie Farinella wrote: I'm trying to install OpenBSD 5.4 on a Dell Vostro 400, it's several years old but not ancient. 4GB RAM, 250GB Seagate ST3250310AS hard drive. The installation goes normally until it tries to find the hard drive and then tells me no hard drive is available. I've wiped the drive (it had ESXi on it before), repartitioned it, unpartitioned it, installed Linux, installed FreeBSD all without problem, but no matter what I do to it, OpenBSD won't see it. I would really like to get this working so any suggestions or guidance is very much appreciated. First of all, your report sucks. Normally, I try to just ignore bad reports, even when I have a possible W.A.G., but I'm going to try something new... I'm going to say you owe the project a $50 donation if I'm right. And if I'm wrong, you get to buy the 5.5 CDs when they come out and say ha ha! you were WRONG! First of all, if you hooked the drive up properly and it is seen in the bios and all, it isn't a matter of the /drive/ not being recognized, or anything on the drive left over, there's something wrong with the handling of the drive by the interface. All that stuff that goes scrolling by the screen on boot? it's important. it's called the dmesg. Read it, it will tell you why things didn't work. You may well have to interpret things, but somewhere on your dmesg, the chip that is your SATA interface will show up, and right there, it will probably give you a good idea why it isn't acting like a disk interface. And while it looks like gibberish, it's actually fairly readable. My wild guess: you have an ahci interface (this is good), configured in the BIOS for RAID (this is bad). Dell shipped a lot of machines with one disk, with the interface configured in the BIOS as a RAID. This is really just a lame BIOS-assisted OS-based RAID system, like most cheap RAID options, but if the OS doesn't support the RAID idea and it is a multi-booting system, bad things can happen when the BIOS helps you by copying one drive over your other drive, so OpenBSD (and at least some Linux kernels, I've seen) won't touch the drive if it was in the unsupported RAID configuration mode. Nick.
Test Mail
Test Mail, to check if its working...
