Re: Pledge(2) appears to kill /usr/bin/openssl enc....
Hello misc@. Previous mail was intended bugs@ Regards. Gerald Hanuer
Re: Pledge(2) appears to kill /usr/bin/openssl enc....
> Pledge(2) appears to kill /usr/bin/openssl enc
>
> 29093 openssl CALL kbind(140187732356888,24,-2708749615844173383)
> 29093 openssl RET kbind 0
> 29093 openssl CALL open(0x862a03bea3f,0)
> 29093 openssl NAMI "/dev/tty"
> 29093 openssl RET open 4
> 29093 openssl CALL
> open(0x862a03bea3f,0x601,0666)
> 29093 openssl NAMI "/dev/tty"
> 29093 openssl RET open 5
> 29093 openssl CALL kbind(140187732356808,24,-2708749615844173383)
> 29093 openssl RET kbind 0
> 29093 openssl CALL ioctl(4,TIOCGETA,0x862a0711160)
> 29093 openssl PSIG SIGKILL SIG_DFL
>
> Adding ( tty ioctl ) separately and together did not correct the issue.
> Same ktrace(1) output as above.
>
> /usr/bin/openssl enc... was working as of Sep 25 current.
> Not sure when this stopped working, it was noticed Oct 15.
Let me show the debugging technique again.
1. use a sed script to add "abort" to all the pledge() calls.
2. make clean; make DEBUG=g
3. gdb obj/openssl
(gdb) run enc -rc4
307 if (tcgetattr(fileno(tty_in), &tty_orig) == -1) {
As expected, that ioctl is being called using the POSIX tc* wrappers.
(gdb) where
#0 0x19cd1989ab9a in ioctl () at :2
#1 0x19ccf470ee85 in open_console (ui=Variable "ui" is not available.
)
at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/ui/ui_openssl.c:307
#2 0x19ccf470afd2 in UI_process (ui=0x19ccaf547c80)
at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/ui/ui_lib.c:459
#3 0x19ccf46f50cf in EVP_read_pw_string_min (buf=0x19cd97705600 "", min=0,
len=Variable "len" is not available.
)
at /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/evp_key.c:117
#4 0x19caae431bca in enc_main () from /usr/obj/usr.bin/openssl/openssl
#5 0x19caae437466 in do_cmd () from /usr/obj/usr.bin/openssl/openssl
#6 0x19caae437d6b in main () from /usr/obj/usr.bin/openssl/openssl
So basically, the latest addition of pledges to the openssl command
were accidentally done without paying attention to part of the program
which hides in the "ui" directory of the library.
I'll let people more familiar with the pledge strategy in that program
fix it.
Pledge(2) appears to kill /usr/bin/openssl enc....
Hello bugs@. Pledge(2) appears to kill /usr/bin/openssl enc 29093 openssl CALL kbind(140187732356888,24,-2708749615844173383) 29093 openssl RET kbind 0 29093 openssl CALL open(0x862a03bea3f,0) 29093 openssl NAMI "/dev/tty" 29093 openssl RET open 4 29093 openssl CALL open(0x862a03bea3f,0x601,0666) 29093 openssl NAMI "/dev/tty" 29093 openssl RET open 5 29093 openssl CALL kbind(140187732356808,24,-2708749615844173383) 29093 openssl RET kbind 0 29093 openssl CALL ioctl(4,TIOCGETA,0x862a0711160) 29093 openssl PSIG SIGKILL SIG_DFL Adding ( tty ioctl ) separately and together did not correct the issue. Same ktrace(1) output as above. /usr/bin/openssl enc... was working as of Sep 25 current. Not sure when this stopped working, it was noticed Oct 15. Regards. Gerald Hanuer
Re: CD's arrived
On 10/14/15, Amarendra Godbole wrote: > And in San Francisco, CA. > > Now I can attach a face to a name! Neato... but I spy a typo in ratchov's index :) Excellent work everyone and Happy 20th! --patrick
Re: mk.conf in examples?
Hi, li...@wrant.com wrote on Fri, Oct 16, 2015 at 03:38:25PM +0300: > Is examples a good candidate for samples of everything etc that the > user may be wondering about compared to only contain examples for base > system daemons? Of course. For example, /etc/examples/pf.conf is not misplaced, even though pf(4) is not a daemon. > Would the user benefit from a sane starting point for other configs, > optionally when none are already in etc? Usually, no. We strive for "sane and secure by default", for all subsystems. Ideally, that works with no configuration file whatsoever. Ideally, if a user has one special need, they create a configuration file from scratch putting in just that one setting, so they get a configuration file of less than five lines. If five users have five different special needs, ideally, their configuration files won't have a single line in common. If a service needs a substantial configuration file for standard operation, it's ill-designed. Of course, there are exceptions for unusually complex services. For example, you can't possibly run bgpd(8) without providing a substantial amount of information in the configuration file about your site, your neigbors and peers. But having a file in /etc/examples/ ought to be the exception rather than the rule for a service. Yours, Ingo
Re: mk.conf in examples?
> > Should mk.conf(5) be present in /etc/examples, or is it not there on > > purpose? > > After hier(7): > > /etc/ System configuration files and scripts. > ... > examples/ Example configuration files for base system daemons. > > So I don't think so :^) While this may not be the case for mk.conf(5) there are other cases this question may concern. Better escalate this instead of decisively ruling out reconsideration. Is examples a good candidate for samples of everything etc that the user may be wondering about compared to only contain examples for base system daemons? Would the user benefit from a sane starting point for other configs, optionally when none are already in etc?
Re: mk.conf in examples?
Hi Antoine, Antoine Jacoutot wrote on Fri, Oct 16, 2015 at 02:26:12PM +0200: > On Fri, Oct 16, 2015 at 02:21:38PM +0200, Ingo Schwarze wrote: >> Jan Stary wrote on Fri, Oct 16, 2015 at 08:17:49AM +0200: >>> Should mk.conf(5) be present in /etc/examples, >>> or is it not there on purpose? >> Not every potential configuration file needs an example. >> As a general direction, i'd rather aim for reducing the number of >> files in /etc/examples/ than proliferating it. The problem is that >> the directory dilutes documentation. Instead of having all the >> documentation in one place, it makes you look in two places, the >> manual and /etc/examples/, doubling the work you have to do when >> changing a configuration, and creating a risk that some people look >> at one place and don't even realize the other exists. It also >> doubles the documentation maintenance work and the risk of documentation >> getting outdated and contradictory, so grand total, it kind of >> quadruples the risk of people misconfiguring their system. >> >> The concept was introduced to reduce the number of files in /etc/, >> and that worked well. That doesn't mean all the examples files > There's also a side effect that sysmerge used. If an example file > changes, it could mean the configuration syntax changed -- sysmerge > will warn you. If we are to remove half of the examples (which I have > no problem with), then I don't think sysmerge should warn anymore. I have no problem with removing that warning feature if you think that it simplifies the sysmerge code and makes maintenance easier. Then again, there doesn't seem anything wrong with that warning staying around even if the number of files should ever dwindle. Some of the more complicated will very probably stay for a long time, and for those, such a warning is potentially useful. For files like /etc/examples/hosts.lpd, the warning is already unimportant right now, deleting them makes no real difference for sysmerge users. Yours, Ingo
Re: mk.conf in examples?
On Fri, Oct 16, 2015 at 02:21:38PM +0200, Ingo Schwarze wrote: > Hi Jan, > > Jan Stary wrote on Fri, Oct 16, 2015 at 08:17:49AM +0200: > > > Should mk.conf(5) be present in /etc/examples, > > or is it not there on purpose? > > Not every potential configuration file needs an example. > As a general direction, i'd rather aim for reducing the number of > files in /etc/examples/ than proliferating it. The problem is that > the directory dilutes documentation. Instead of having all the > documentation in one place, it makes you look in two places, the > manual and /etc/examples/, doubling the work you have to do when > changing a configuration, and creating a risk that some people look > at one place and don't even realize the other exists. It also > doubles the documentation maintenance work and the risk of documentation > getting outdated and contradictory, so grand total, it kind of > quadruples the risk of people misconfiguring their system. > > The concept was introduced to reduce the number of files in /etc/, > and that worked well. That doesn't mean all the examples files There's also a side effect that sysmerge used. If an example file changes, it could mean the configuration syntax changed -- sysmerge will warn you. If we are to remove half of the examples (which I have no problem with), then I don't think sysmerge should warn anymore. -- Antoine
Re: mk.conf in examples?
Hi Jan, Jan Stary wrote on Fri, Oct 16, 2015 at 08:17:49AM +0200: > Should mk.conf(5) be present in /etc/examples, > or is it not there on purpose? Not every potential configuration file needs an example. As a general direction, i'd rather aim for reducing the number of files in /etc/examples/ than proliferating it. The problem is that the directory dilutes documentation. Instead of having all the documentation in one place, it makes you look in two places, the manual and /etc/examples/, doubling the work you have to do when changing a configuration, and creating a risk that some people look at one place and don't even realize the other exists. It also doubles the documentation maintenance work and the risk of documentation getting outdated and contradictory, so grand total, it kind of quadruples the risk of people misconfiguring their system. The concept was introduced to reduce the number of files in /etc/, and that worked well. That doesn't mean all the examples files should stay. Some file formats are complicated enough that moving all the examples to the manual page would make the manual page unwieldy, and those example files are probably there to stay. But for trivial cases - the most extreme one being /etc/examples/hosts.lpd - i'd definitely love to get rid of such files. The mk.conf(5) format is so trivial that it apparently doesn't even need EXAMPLES in the manual page (or if it turns out a specific example might be useful, it could easily be added there). A dedicated examples file would clearly be overkill. Yours, Ingo
Re: OpenBGPd on OpenBSD 5.5 crashed after adding a new peer
On 2015-10-15, Theo de Raadt wrote: >> OpenBGPd on OpenBSD 5.5 crashed after adding a new peer with following >> messages. >> On a second box with 5.7 and the same configuration there are no problems. >> OpenBGPd is configured as route-server. >> >> Any tips for configuration changes to prevent this on 5.5? > > Upgrade. 5.5 is EOL. If you're deliberately keeping them on separate versions to reduce the chance of a common bug affecting both machines, updating the 5.5 box to 5.8 (released this weekend) would be worth considering. > Our kind of software does not stand still. Here's the facts: > > % cvs diff -rOPENBSD_5_5_BASE -rHEAD | wc > cvs diff: Diffing . > 3955 15180 115686 to be clear, that's just in bgpd ;)
Re: Install on compact flash
On 2015-10-15 Thu 16:01 PM |, Kenneth Gober wrote: > > You may also want to move cron log files from /var/cron to /var/log (or > /var/log/cron if you want them to be separated from other logs). Doing so > involves modifying /etc/syslog.conf and /etc/newsyslog.conf. If you do > this be prepared for warnings in the nightly security check emails due to the > cron log file not being found in its normal location. Leaving an empty log > file in the original location is one workaround for this but I haven't tried > it. That stops the security alerts. > A better workaround may be to modify the nightly check so that it looks > for the log file in its new location. > Relocate the line in /etc/mtree/special -- The Heineken Uncertainty Principle: You can never be sure how many beers you had last night.
Re: Asterisk + MariaDB + ODBC newbie questions
On 15.10.2015 г. 04:45 ч., Chris Cappuccio wrote:
Stuart Henderson [s...@spacehopper.org] wrote:
On 2015-10-14, Ivo Chutkin wrote:
Hello all,
I want to use Asterisk with MariaDB CDR backend.
I have working Asterisk.
I have working MariaDB.
As far as I understand, since Asterisk 11 I must use ODBC connector to
MariaDB.
Unfortunately I cannot find any practical info concerning OpenBSD,
Asterisk, ODBC and MariaDB.
I tried iodbc package but I cannot find mysql drivers.
The iodbc package just contains the ODBC library, it doesn't come with
any database drivers itself. AFAIK at the moment the only drivers we have
are sybase/sql server (in the "freetds" package), postgresql (the
"postgresql-odbc" package) and access ("mdbtools").
I think you need either "MariaDB Connector/ODBC" or "MySQL Connector/ODBC"
but these aren't in ports/packages yet.
In my experience asterisk is more reliable with text cdr logging. Creating
a script to import CSV into the mysql cli tool is trivial.
Hi Chris and Stuart,
Thanks for replies.
At least I did not miss anything obvious :-)
As I took deep thought, Chris idea for importing csv is much better than
including more software (problems) in the equation.
Thanks for the info and ideas.
Ivo
Re: mk.conf in examples?
On Fri, Oct 16, 2015 at 07:17:49AM BST, Jan Stary wrote: > Should mk.conf(5) be present in /etc/examples, or is it not there on > purpose? Hi Jan, After hier(7): /etc/ System configuration files and scripts. ... examples/ Example configuration files for base system daemons. So I don't think so :^) Raf
