Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Philip Guenther]

On Mon, 25 Sep 2017, Theodore Wynnychenko wrote:
> I noticed this message in the dmesg after updating -current yesterday.
> 
> I am not sure what it means.
>
> There is no file "test-ld.so" anywhere on the system that I can find.  
> I also see that it appears this part of rc was just committed in the 
> last few weeks.
> 
> Why is this happening, and is there anything that I should do to correct 
> the "Permission denied" error?

It means that after /etc/rc had built a new ld.so, when it tried to test 
it by running the test-ld.so program (which is packaged inside 
/usr/libdata/ld.so.a), it failed with that error, EACCES.

My guess is that you're hitting this:

 [EACCES]   The new process file is on a filesystem mounted with
execution disabled (MNT_NOEXEC in ).

If you're mounting /tmp with the noexec flag, then stop doing that.


Philip Guenther

Re: apache2 cgi script stopped working with -current about April 2017

[Theodore Wynnychenko]

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Stuart
Henderson
Sent: Sunday, September 24, 2017 2:43 PM
To: misc@openbsd.org
Subject: Re: apache2 cgi script stopped working with -current about April 2017

On 2017-09-24, Theodore Wynnychenko  wrote:
> This was working for years, until about April or May.  Then, after an update
of
> the base system (and before an update of the installed packages), I noticed
the
> scripts had stopped working.  I updated the packages, and the scripts
continued
> to not work.

First thing I'd try is updating the copies of binaries/libraries/ld.so inside
the chroot jail.




Thank you.

I don't know why I just didn't do that to begin with, as it was not a hard thing
to do (especially since I was wasting all sorts of time looking for more
esoteric causes).

So, I updated the libraries and binaries in the chroot, and the scripts work.

I think I was confused by the fact that the scripts worked from the shell using
the chroot command; but, I am guessing, the call from the running apache2
process is not _exactly_ the same.

Thanks





---
This email has been checked for viruses by AVG.
http://www.avg.com

reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Theodore Wynnychenko]

Hello

I noticed this message in the dmesg after updating -current yesterday.

I am not sure what it means.

There is no file "test-ld.so" anywhere on the system that I can find.  I also
see that it appears this part of rc was just committed in the last few weeks.

Why is this happening, and is there anything that I should do to correct the
"Permission denied" error?


Thank you.
Ted



---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: libusb device name other than ugen

[Mihai Popescu]

> You might try to tell the kernel *not* to attach the device to ucom(4).

It will attach like uftdi or other * found in ucom man page.
Dmesg is really needed!

Re: Strange sed substitution removes text

[Martijn van Duren]

On 09/25/17 09:15, Andreas Kusalananda Kähäri wrote:
> Yes, this seems to fix this particular issue for me nicely,
> but the "int i = 0;" is probably not needed.

You're right, that part was from some debugging printfs.
I also wasn't asking for OKs, but merely pointing out the root of
problem.

Lets just wait until Ingo has time to look into it. He's still on
holiday in Paris, so it might be a few days.
> 
> 
> On Sun, Sep 24, 2017 at 11:59:49PM +0200, Martijn van Duren wrote:
>> and now with 100% more patch...
>>
>> Index: process.c
>> ===
>> RCS file: /cvs/src/usr.bin/sed/process.c,v
>> retrieving revision 1.32
>> diff -u -p -r1.32 process.c
>> --- process.c22 Feb 2017 14:09:09 -  1.32
>> +++ process.c24 Sep 2017 21:58:14 -
>> @@ -336,6 +336,7 @@ substitute(struct s_command *cp)
>>  int n, lastempty;
>>  size_t le = 0;
>>  char *s;
>> +int i = 0;
>>  
>>  s = ps;
>>  re = cp->u.s->re;
>> @@ -386,7 +387,7 @@ substitute(struct s_command *cp)
>>   * and at the end of the line, terminate.
>>   */
>>  if (match[0].rm_so == match[0].rm_eo) {
>> -if (*s == '\0' || *s == '\n')
>> +if (*s == '\0')
>>  slen = -1;
>>  else
>>  slen--;
>>
>>
>> On 09/24/17 23:57, Martijn van Duren wrote:
>>> This fixes the issue for me, but I'm not sure about the motivation
>>> behind the check.
>>> Maybe schwarze@ can shed some light on it, since he's to (cvs) blame for
>>> the particular line.
>>>
>>> martijn@
>>>
>>> On 09/24/17 15:42, Andreas Kusalananda Kähäri wrote:
 Hi,

 Given the input file of three lines:

 line 1
 line 2
 line 3

 and the sed script

 s/\>>> /g
 s/^/hello/

 which inserts a newline in front of every word and then prepends the
 word "hello" to the beginning of the pattern space.

 The following happens:

 $ sed -f script.sed input.txt
 hello

 hello

 hello


 I was expecting to get

 hello
 line
 1
 hello
 line
 2
 hello
 line
 3

 This is a bit surprising since running only the first sed expression
 gives (as expected)


 line
 1

 line
 2

 line
 3


 The question is, why does the "line N" data disappear when inserting a
 word at the start of the pattern space here?

 I'm also noticing that this does not happen if a space (for instance)
 precedes the escaped newline in the first expression:

 s/\>>> /g
 s/^/hello/


 This is using sed in the base system on OpenBSD 6.1-stable (amd64).

 Cheers,

>>>
> 

Re: libusb device name other than ugen

[Marcus MERIGHI]

robert.d...@yahoo.fr (Robert Dazi), 2017.09.24 (Sun) 22:28 (CEST):
>  Hi,I have a software (openocd) that needs to serially communicate
>  with a board, but it can't because libusb throws
>  LIBUSB_ERROR_NOT_SUPPORTED. 
> To access a usb device using libusb, libusb provides a function
> returning a list of devices. But this function fills a field of the
> device structure only if the device pathname starts with "ugen",
> otherwise the field is set to NULL.But a NULL field leads to the
> _sync_gen_transfer to return "LIBUSB_ERROR_NOT_SUPPORTED". 
> But my device is bound to cuaU1, and not to any ugen. 
> This assumption of a "ugen" name is also in _access_endpoint. 
> 
> Do I need to patch libusb, or is it simply a mistake of mine

You might try to tell the kernel *not* to attach the device to ucom(4).

For a quick test whether that helps, do
a) reboot.
b) at the boot prompt type "-c", enter.
c) you will find yourself at a ukc> prompt.
d) type "disable ucom", enter.
e) type "quit", enter.
f) boot will continue.
g) when plugging your ucom(4) device you should see your device *not*
   attaching as ucom(4).
h) use the device as ugen(4).

For a permanent solution, run config -o /bsd.new -e /bsd, do the
changes as above, then move /bsd /bsd.ori and /bsd.new to /bsd. 

Marcus

Re: running spamd on firewall ord on the mailsystem

[Boudewijn Dijkstra]

Op Tue, 19 Sep 2017 09:35:04 +0200 schreef Peter N. M. Hansteen  
:

On 09/19/17 09:10, rosjat wrote:


I like to get some opinions on where to use the spamd daemon. Is it
better to do the heavy stuff on the firewall or let it all pass to the
mailsystem and do the filtering there?


OpenBSD's spamd is not in any way a 'heavy' service.


Indeed.  On my site, with 12k messages tarpitted last week, spamd (with  
-v) took about the same cpu time as ntpd.  Spamlogd even less.  Together  
about 7.5M resident memory.



It's entirely
possible to run it on the actual mail server, but I tend to recommend
stopping unwanted traffic early and set up on the directly
internet-facing host (aka the firewall).


Note that the spamd(8) manual page assumes it's the same machine, so using  
different machines is a less trivial pf.conf setup.  IIRC it requires  
route-to in stead of divert-to for your whitelist(s), or a divert-to with  
a relayd/nc relay.




--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Re: Strange sed substitution removes text

[Andreas Kusalananda Kähäri]

Yes, this seems to fix this particular issue for me nicely,
but the "int i = 0;" is probably not needed.


On Sun, Sep 24, 2017 at 11:59:49PM +0200, Martijn van Duren wrote:
> and now with 100% more patch...
> 
> Index: process.c
> ===
> RCS file: /cvs/src/usr.bin/sed/process.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 process.c
> --- process.c 22 Feb 2017 14:09:09 -  1.32
> +++ process.c 24 Sep 2017 21:58:14 -
> @@ -336,6 +336,7 @@ substitute(struct s_command *cp)
>   int n, lastempty;
>   size_t le = 0;
>   char *s;
> +int i = 0;
>  
>   s = ps;
>   re = cp->u.s->re;
> @@ -386,7 +387,7 @@ substitute(struct s_command *cp)
>* and at the end of the line, terminate.
>*/
>   if (match[0].rm_so == match[0].rm_eo) {
> - if (*s == '\0' || *s == '\n')
> + if (*s == '\0')
>   slen = -1;
>   else
>   slen--;
> 
> 
> On 09/24/17 23:57, Martijn van Duren wrote:
> > This fixes the issue for me, but I'm not sure about the motivation
> > behind the check.
> > Maybe schwarze@ can shed some light on it, since he's to (cvs) blame for
> > the particular line.
> > 
> > martijn@
> > 
> > On 09/24/17 15:42, Andreas Kusalananda Kähäri wrote:
> >> Hi,
> >>
> >> Given the input file of three lines:
> >>
> >> line 1
> >> line 2
> >> line 3
> >>
> >> and the sed script
> >>
> >> s/\ >> /g
> >> s/^/hello/
> >>
> >> which inserts a newline in front of every word and then prepends the
> >> word "hello" to the beginning of the pattern space.
> >>
> >> The following happens:
> >>
> >> $ sed -f script.sed input.txt
> >> hello
> >>
> >> hello
> >>
> >> hello
> >>
> >>
> >> I was expecting to get
> >>
> >> hello
> >> line
> >> 1
> >> hello
> >> line
> >> 2
> >> hello
> >> line
> >> 3
> >>
> >> This is a bit surprising since running only the first sed expression
> >> gives (as expected)
> >>
> >>
> >> line
> >> 1
> >>
> >> line
> >> 2
> >>
> >> line
> >> 3
> >>
> >>
> >> The question is, why does the "line N" data disappear when inserting a
> >> word at the start of the pattern space here?
> >>
> >> I'm also noticing that this does not happen if a space (for instance)
> >> precedes the escaped newline in the first expression:
> >>
> >> s/\ >> /g
> >> s/^/hello/
> >>
> >>
> >> This is using sed in the base system on OpenBSD 6.1-stable (amd64).
> >>
> >> Cheers,
> >>
> > 

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.