договаривались сегодня увидеться
?This is a text part of the message. It is shown for the users of old-style e-mail clients
Re: prong: keep your daemons alive and report if they are fataly wounded.
Gilles Chehade poolp.org> writes: > Also, restarting a daemon that has crashed because of an exploit means > you expose it again with maybe less luck next time (kindly reminded by > mail Right, that's a valid point. In that case you'd only want an email to be sent. Either way, my script is from experience in production environments where daemons usually died for silly reasons which had nothing to do with break in attempts. A script like this is the difference between angry customers calling you out of bed in the middle of the night and waking up in the morning reading emails about services which stopped for no good reasons and nobody but me noticing while still being able to analyse and fix the problem. I'll ponder on your remarks and see if I come up with something. # Han
Re: prong: keep your daemons alive and report if they are fataly wounded.
On Fri, Aug 24, 2012 at 10:21:12PM +0200, Gilles Chehade wrote: > > Unless things have changed, I was told in 2008 that this kind of > tools is not going to hit our tree because it's not unix ;-) > Also, restarting a daemon that has crashed because of an exploit means you expose it again with maybe less luck next time (kindly reminded by mail ;-) -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: prong: keep your daemons alive and report if they are fataly wounded.
On Fri, Aug 24, 2012 at 08:53:55PM +0200, Han Boetes wrote: > Hi, > Hi Han, > This is my idea of how to implement this functionality. Rather > simple and transparent. If you like the idea but think you can > make a better implementation feel free to make it.. > For what it's worth, I had a similar project: https://poolp.org/~gilles/projects/procstated/ I don't know if it's a "better" implementation, but it used to do the job quite well for my needs back then ;-) > Yes there are other implementations that can do about the same, > but I wanted to write something the OpenBSD way. > > I hope the OpenBSD team at least likes the idea enough to > implement something like this for one of the next releases. > Unless things have changed, I was told in 2008 that this kind of tools is not going to hit our tree because it's not unix ;-) -- Gilles Chehade https://www.poolp.org @poolpOrg
prong: keep your daemons alive and report if they are fataly wounded.
Hi, This is my idea of how to implement this functionality. Rather simple and transparent. If you like the idea but think you can make a better implementation feel free to make it.. Yes there are other implementations that can do about the same, but I wanted to write something the OpenBSD way. I hope the OpenBSD team at least likes the idea enough to implement something like this for one of the next releases. Download: http://homepage.boetes.org/software/prong.tgz The README: WHY PRONG? Since the introduction of the initscript in /etc/rc.d only one functionality has been missing: the option to automatically restart failed services and to report on them incase they won't come up again. Now for some useless info: Why "prong"? 1) It's one of my favourite bands. 2) The item that chucky is holding in his hands is a prong. It's used to prod on daemons! HOW IT WORKS: First read and then run ./setup, it creates symlinks for all running daemons in the prong.d directory. Then create a cronjob for prong. So add a line like "*/3 * * * * /etc/prong.d/prong" with "crontab -e" to make prong run once in the three minutes. And then test everything by disabling a not so important daemon: "/etc/rc.d/ntpd stop" and notice how it automatically revives and that the name of the symlink is changed temporarily. WORKING WITH PRONG: The status command for prong is: "ls -l /etc/prong.d/*.*" All symlinks in this directory that start with d. are disabled. All symlinks in this directory that start with e. are enabled. All symlinks in this directory that start with f. have failed. So the idea is that if you want to temporarily prevent prong from restarting a daemon -- for maintainance purposes -- you'd: mv e.daemon d.daemon You can edit all scripts to do what you please. I think the only script you will really want to edit is the alert script. But do take a look at all scripts and read them and try to understand how they work. Start with prong itself. Notice that at the moment nothing is done with failed and disabled daemons? That's by design, but in your case you might want to change it. LICENSE: Public domain! Go away! Leave me alone! # Han
[cwm] ssh menu: match on any part of input
I don't know about you guys, but:
1) I can recall last octet of an IP address more often than the first,
2) I have a lot of machines in the same /24 subnet.
diff --git a/kbfunc.c b/kbfunc.c
index 9bbf802..9f1fdb1 100644
--- a/kbfunc.c
+++ b/kbfunc.c
@@ -377,7 +377,7 @@ kbfunc_ssh(struct client_ctx *cc, union arg *arg)
(void)fclose(fp);
if ((mi = menu_filter(sc, &menuq, "ssh", NULL, 1, 0,
- search_match_exec, NULL)) != NULL) {
+ search_match_text, NULL)) != NULL) {
if (mi->text[0] == '\0')
goto out;
l = snprintf(cmd, sizeof(cmd), "%s -e ssh %s", Conf.termpath,
Re: Perl 5.16.1 testing for inclusion in base
On Sat, Aug 18, 2012 at 04:01:29PM -0700, Andrew Fresh wrote: > I have been working on getting a newer perl tested for import into OpenBSD. I > put some work into splitting the patches by function in hopes of pushing as > many as possible upstream and to make testing future versions of perl easier. > > What I've been working on is available here: > http://cvs.afresh1.com/~andrew/perl-update/ > > I could use some additional testers for other archs, see below for a > list of architectures that still need to be tested. > > If you want to test it, I tried to make it fairly simple: > * download http://cvs.afresh1.com/~andrew/perl-update/perl-update.tar.gz > * extract someplace - tar xvf perl-update.tar.gz > * copy perl-5.16.1.tar.gz into the same directory > * I have a copy available, but you can get it wherever > * cd perl-update && ftp > http://cvs.afresh1.com/~andrew/perl-update/perl-5.16.1.tar.gz > * cd to someplace you have room to build (around 200M on amd64) > * run /path/to/perl-update/build_local_perl > * wait > * If you get "All tests successful", send me an email and let me know > > * otherwise, try it again without the local patches > * NO_LOCAL_PATCHES=1 /path/to/perl-update/build_local_perl > * and send me both logs > > Perl 5.16.1 (with usethreads) testing status: > * alpha: > * amd64: I'm winning, I'm winning! (afresh1) > * armish: > * hppa: > * i386: I'm winning, I'm winning! (afresh1) > * landisk: > * loongson: loongson is ok :) -- Pierre-Emmanuel André GPG key: 0x7AE329DC
Re: Small change to let mg handle localized characters
On 08/24/2012 08:32 AM, Stefan Sperling wrote: On Thu, Aug 23, 2012 at 07:19:29PM -0400, Geoff Steckel wrote: Well, yes, using a character set conversion API in stupid ways can munge data. How does that relate to anything I was saying? As long as iconv is only used to display data, not to change file contents, you're perfectly right. Yes, that's what I meant (sorry if I wasn't clear enough). Open the file, allow the user to specify the file's encoding (and maybe auto-detect it somehow, but always allow the user to override this), load the data into a buffer, convert the buffer for display, and show it on the screen. The user can now edit the buffer in the display encoding. Before saving, convert back to the file's encoding. If that fails because the user added characters that cannot be represented in the original encoding, complain and offer the option to save the file in a suitable encoding. A real example is a L***x editor using iconv. Open a 5000 line file, change line 100, line 500 contains a non-conforming character, file is truncated there. Not pretty. Yeah, that's obviously not done right. We can easily imagine other problems like a mix of character encodings ending up in a file by accident. Sometimes this is done on purpose however and then the display conversion step gets interesting, but at a minimum it should display one of the encodings correctly and allow users to switch the display encoding if necessary. Another real example. Bring up line containing non-conforming character. Line appears blank. I agree that it takes a great deal of care to implement a multi-character set editor such that it works on all useful files while displaying in a particular locale's character set. Yes, not every combination can be made to work. E.g. displaying any of the non-latin1 subset of UTF-8 in a latin1 locale just won't work, and this must be treated as a user error (invalid input or locale configuration). And that's fine since it's an expected failure mode. It just needs to be handled in a way that doesn't destroy data. It isn't a trivial task on all accounts but the result would be useful. But for this kind of feature to appear in mg we'll need iconv in base. As a first step, adding a UTF-8 mode to mg, where file content is expected to be UTF-8 encoded, would be much easier and already quite useful. Alas, I've managed club membership lists with a mix of names from many countries. In order to print these, I've had to edit in hex UTF-8 and then download all the glyphs to the printer. Luckily I had a program which would automatically do the glyph loading. Printing a list of CD contents presented the same problem. These would seem to be valid files with multiple irreconcilable character sets. At least I didn't have to deal with bidirectional encodings. Another time I was making banners for my office for all the immigrants and expatriates. Then I did have to deal with bidirectional characters. It was an interesting problem: I can't read Arabic or Hangul script, switching locales before each edit was incredibly error-prone, and most of the banners needed to have an American-English transliteration, interpretation, or alternate "English" name. It's difficult to create a useful tool that doesn't require the user to deal with \u+ at least some of the time and still presents a pleasing display. I really think iconv should have a variant which emits a unique and displayable alternate decoding for any character not in the current locale and does a unique reverse encoding for output. That would allow editing of any file in any locale while presenting a simple and intuitive display for the great majority of cases. It would be reasonable to emit a warning to the user for mixed character sets. Geoff Steckel
Re: Small change to let mg handle localized characters
On Fri, Aug 24, 2012 at 02:00:15PM +, Christian Weisgerber wrote: > Stefan Sperling wrote: > > > An editor needs to convert between character sets. > > Does it? See ":help fileencoding" in vim for documentation of a working implementation. > > How else are you going to display a latin1 file in a UTF-8 locale, > > for example? > > You don't. You throw up an error. That requires the user to run iconv manually and edit the converted file. Can be done, sure, but I wouldn't find that very convenient. Then again, I don't use mg. I'm just offering my opinion on the patch, and why I think it's not the right solution. If mg users don't agree, just ignore me.
Re: Small change to let mg handle localized characters
Stefan Sperling wrote: > An editor needs to convert between character sets. Does it? > How else are you going to display a latin1 file in a UTF-8 locale, > for example? You don't. You throw up an error. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Small change to let mg handle localized characters
On Thu, Aug 23, 2012 at 07:19:29PM -0400, Geoff Steckel wrote: > >Well, yes, using a character set conversion API in stupid ways can > >munge data. How does that relate to anything I was saying? > As long as iconv is only used to display data, not to change file > contents, you're perfectly right. Yes, that's what I meant (sorry if I wasn't clear enough). Open the file, allow the user to specify the file's encoding (and maybe auto-detect it somehow, but always allow the user to override this), load the data into a buffer, convert the buffer for display, and show it on the screen. The user can now edit the buffer in the display encoding. Before saving, convert back to the file's encoding. If that fails because the user added characters that cannot be represented in the original encoding, complain and offer the option to save the file in a suitable encoding. > A real example is a L***x editor using iconv. Open a 5000 line file, > change line 100, line 500 contains a non-conforming character, > file is truncated there. > > Not pretty. Yeah, that's obviously not done right. We can easily imagine other problems like a mix of character encodings ending up in a file by accident. Sometimes this is done on purpose however and then the display conversion step gets interesting, but at a minimum it should display one of the encodings correctly and allow users to switch the display encoding if necessary. > Another real example. Bring up line containing non-conforming character. > Line appears blank. > > I agree that it takes a great deal of care to implement a multi-character > set editor such that it works on all useful files while displaying in > a particular locale's character set. Yes, not every combination can be made to work. E.g. displaying any of the non-latin1 subset of UTF-8 in a latin1 locale just won't work, and this must be treated as a user error (invalid input or locale configuration). And that's fine since it's an expected failure mode. It just needs to be handled in a way that doesn't destroy data. It isn't a trivial task on all accounts but the result would be useful. But for this kind of feature to appear in mg we'll need iconv in base. As a first step, adding a UTF-8 mode to mg, where file content is expected to be UTF-8 encoded, would be much easier and already quite useful.
ntpd(8) option to provide time even when not being synced
the diff below adds an option to the ntpd(8), which has him provide
time, even though he's not synced.
ok?
Index: ntpd.8
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.8,v
retrieving revision 1.31
diff -u -r1.31 ntpd.8
--- ntpd.8 17 Sep 2011 10:22:00 - 1.31
+++ ntpd.8 24 Aug 2012 11:17:17 -
@@ -23,7 +23,7 @@
.Sh SYNOPSIS
.Nm ntpd
.Bk -words
-.Op Fl dnSsv
+.Op Fl dinSsv
.Op Fl f Ar file
.Ek
.Sh DESCRIPTION
@@ -47,6 +47,9 @@
.Nm
will run in the foreground and log to
.Em stderr .
+.It Fl i
+Provide time, even though the time is
+not synced.
.It Fl f Ar file
Use
.Ar file
Index: ntpd.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
retrieving revision 1.69
diff -u -r1.69 ntpd.c
--- ntpd.c 19 Mar 2011 23:40:11 - 1.69
+++ ntpd.c 24 Aug 2012 11:17:17 -
@@ -73,7 +73,7 @@
{
extern char *__progname;
- fprintf(stderr, "usage: %s [-dnSsv] [-f file]\n", __progname);
+ fprintf(stderr, "usage: %s [-dinSsv] [-f file]\n", __progname);
exit(1);
}
@@ -97,13 +97,16 @@
log_init(1);/* log to stderr until daemonized */
- while ((ch = getopt(argc, argv, "df:nsSv")) != -1) {
+ while ((ch = getopt(argc, argv, "df:insSv")) != -1) {
switch (ch) {
case 'd':
lconf.debug = 1;
break;
case 'f':
conffile = optarg;
+ break;
+ case 'i':
+ lconf.ignore_sync = 1;
break;
case 'n':
lconf.noaction = 1;
Index: ntpd.h
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.h,v
retrieving revision 1.105
diff -u -r1.105 ntpd.h
--- ntpd.h 21 Sep 2011 16:38:05 - 1.105
+++ ntpd.h 24 Aug 2012 11:17:17 -
@@ -180,6 +180,7 @@
u_int8_tdebug;
u_int8_tnoaction;
u_int8_tfilters;
+ u_int8_tignore_sync;
};
enum imsg_type {
Index: server.c
===
RCS file: /cvs/src/usr.sbin/ntpd/server.c,v
retrieving revision 1.36
diff -u -r1.36 server.c
--- server.c21 Sep 2011 15:41:30 - 1.36
+++ server.c24 Aug 2012 11:17:17 -
@@ -188,7 +188,7 @@
version = (query.status & VERSIONMASK) >> 3;
bzero(&reply, sizeof(reply));
- if (lconf->status.synced)
+ if (lconf->status.synced || lconf->ignore_sync)
reply.status = lconf->status.leap;
else
reply.status = LI_ALARM;
@@ -200,7 +200,9 @@
else /* ignore packets of different type (e.g. bcast) */
return (0);
- reply.stratum = lconf->status.stratum;
+ /* set stratum to 10 when we're not synced but still provide time */
+ reply.stratum = (lconf->status.synced || !lconf->ignore_sync) ?
+ lconf->status.stratum : 10;
reply.ppoll = query.ppoll;
reply.precision = lconf->status.precision;
reply.rectime = d_to_lfp(rectime);
Re: use time_uptime for various pf expirations
On 22.8.2012. 20:50, Florian Obser wrote: > Hi, > > I think I got this now. > - replace time_seconds with time_uptime > - with that flow_finish in pflow can be simplified (pointed out by benno@) > this should take care of flows with finish < start for localy created > states > - change various variables from unsigned to signed (mainly) in pfsync which > could underflow (inspired by a patch from dlg@ from last year, pointed out > by cameild@). This fixes pflow and at the same time an underflow problem > in pfsync which dlg's patch was addressing. If I understand the history > correctly cameild@ noticed this problem last year. > > Hrvoje Popovski tested an older version without the pfsync fix. > > Since this changes the semantics of a field in pfsync both pfsync machines > need to be updated (I think it's ok to import 5.1 states into this version > but the other way around will cause problems.) > > We are running with this patch since yesterday on a redundant firewall > (amd64) with pfsync and no longer see broken flows (i.e. where finish > < start). The pair survived various failovers. > Hello, I can confirm that there aren't any 4294* flow durations in nfdump (1.6.6). Pfsync is patched and enabled on firewalls and redundancy was tested. Thank you.
Re: Toolchain bump: be careful upgrading from source
Mark Kettenis wrote: > > $ cd /usr/src/gnu/usr.bin/binutils > > You'll want to do a > > $ make -f Makefile.bsd-wrapper $ make -f Makefile.bsd-wrapper obj > here first, otherwise you'll end up with crap in your source directory > that's difficult to get rid of. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: fts(3) traversal priority in cp(1)
On Fri, Aug 24, 2012 at 08:12:49AM +0200, Otto Moerbeek wrote:
> On Thu, Aug 23, 2012 at 01:33:37PM -0700, Philip Guenther wrote:
>
> > On Thu, Aug 23, 2012 at 12:32 PM, Jan Stary wrote:
> > > cp.c says:
> > >
> > > /*
> > > * mastercmp --
> > > * The comparison function for the copy order. The order is to copy
> > > * non-directory files before directory files. The reason for this
> > > * is because files tend to be in the same cylinder group as their
> > > * parent directory, whereas directories tend not to be. Copying the
> > > * files first reduces seeking.
> > > */
> > ...
> > > Doesn't the code actually do the opposite?
> > > If 'a' is a directory, it comes first?
> >
> > Yep. Nice catch.
> >
> >
> > > Should that be FTS_F?
> >
> > I think it's correct to do the test against FTS_D, it just should
> > return them in the other direction to do what the comment says.
> >
> > What I don't know is whether the rule described is actually still
> > considered a good and useful thing still. Otto?
> >
> >
> > Philip Guenther
>
> netbsd removed the sorting in 1.52:
>
> "Remove fts sorting. It was originally put there to copy files
> before directories since files (usually) are in the same cylinder
> group and subdirectories aren't. However, this mostly changed with
> the new ffs dirpref algorithm in 2001."
>
> I'd have to check which dirpref() we use. And do some tests.
>
> That said, the code might not agree with the comment, but as long as files
> stick
> together as a group I do not think it matters much.
>
> -Otto
We used the same "new" dirpref() as freebsd and netbsd. Actually, they
copied gluk@'s code from us ;-)
Netbsd removed sorting citing peformance gains, freebsd has some pr
(http://www.FreeBSD.org/cgi/query-pr.cgi?pr=53475)) requesting that,
but they still have it.
Limited testing here shows no significant difference. I'm all for removing it.
Userland should not guess about filesystem layout policies. The
filesystem might not even be ffs and modern (SSD) disks do not have
any simple relation between blocks and seek times anyway.
So here's a diff.
-Otto
Index: cp.c
===
RCS file: /cvs/src/bin/cp/cp.c,v
retrieving revision 1.34
diff -u -p -r1.34 cp.c
--- cp.c4 Nov 2007 02:01:57 - 1.34
+++ cp.c24 Aug 2012 08:55:12 -
@@ -77,7 +77,6 @@ mode_t myumask;
enum op { FILE_TO_FILE, FILE_TO_DIR, DIR_TO_DNE };
int copy(char *[], enum op, int);
-int mastercmp(const FTSENT **, const FTSENT **);
char *find_last_component(char *);
int
@@ -260,7 +259,7 @@ copy(char *argv[], enum op type, int fts
char *p, *target_mid;
base = 0;
- if ((ftsp = fts_open(argv, fts_options, mastercmp)) == NULL)
+ if ((ftsp = fts_open(argv, fts_options, NULL)) == NULL)
err(1, NULL);
for (rval = 0; (curr = fts_read(ftsp)) != NULL;) {
switch (curr->fts_info) {
@@ -445,30 +444,4 @@ copy(char *argv[], enum op type, int fts
err(1, "fts_read");
(void)fts_close(ftsp);
return (rval);
-}
-
-/*
- * mastercmp --
- * The comparison function for the copy order. The order is to copy
- * non-directory files before directory files. The reason for this
- * is because files tend to be in the same cylinder group as their
- * parent directory, whereas directories tend not to be. Copying the
- * files first reduces seeking.
- */
-int
-mastercmp(const FTSENT **a, const FTSENT **b)
-{
- int a_info, b_info;
-
- a_info = (*a)->fts_info;
- if (a_info == FTS_ERR || a_info == FTS_NS || a_info == FTS_DNR)
- return (0);
- b_info = (*b)->fts_info;
- if (b_info == FTS_ERR || b_info == FTS_NS || b_info == FTS_DNR)
- return (0);
- if (a_info == FTS_D)
- return (-1);
- if (b_info == FTS_D)
- return (1);
- return (0);
}
Re: Toolchain bump: be careful upgrading from source
> Date: Thu, 23 Aug 2012 18:39:28 -0700 > From: Matthew Dempsky > > A few days ago I committed a change to binutils to add support for > .openbsd.randomdata sections and then later converted libc to make use > of them. It seems that at least armish is not happy with libc > compiled using an out-of-date binutils, so if you're following from > source be careful to update binutils first before trying to make > build: > > $ cd /usr/src/gnu/usr.bin/binutils You'll want to do a $ make -f Makefile.bsd-wrapper here first, otherwise you'll end up with crap in your source directory that's difficult to get rid of. I fixed current.html to reflect this. > $ make -f Makefile.bsd-wrapper all > $ make -f Makefile.bsd-wrapper install
Noticias del Mundo Automotor - Agosto 2012 - Autofrance
Si no puede visualizar correctamente el newsletter haga click aqui cabezal_maling peugeot_feline Con él la marca francesa regresa al segmento medianogrande en el cual ha tenido exponentes muy exitosos. Luce el nuevo estilo de diseño y cuenta con un habitáculo amplio, distinguido y con mucha tecnología. Luego de tres generaciones Peugeot vuelve a tener un modelo de la serie 5, con un diseño que muestra los nuevos códigos de estilo de la marca, que habían sido adelantados por el concept car SR1. Puertas adentro su estilo se diferencia notoriamente de otros modelos de la marca, donde también exhibe el nuevo rumbo estilístico. Cuenta con dos niveles de equipamiento: Allure, Feline y ofrece un motor 1.6 litros THP (turbo de alta presión) de 16 válvulas y 163 caballos de fuerza. >>> continuar leyendo... nsr Nota provista por Noticias Sobre Ruedas [IMAGE] peugeot_3008clic Peugeot 3008 Premium Plus Tiptronic Precio de Lista $206.500 Bonificación Autofrance $6.000 Financiación Exclusiva Precio Autofrance $200.500 Anticipo $131.500 24 Ctas. x $4.000 [IMAGE] PLAN NACIONAL AUTOMOTOR 2012 Sólo en Autofrance te bonificamos $10.000 y podés retirar a partir de la 2da cuota! peugeot_207 725 clic Peugeot 207 Active 1.4 5p $725 Final x mes peugeot_308 1251 clic Peugeot 308 Active 1.6N $1.251 Final x mes peugeot_408 1340 clic Peugeot 408 Allure 2.0N $1.340 Final x mes peugeot_parthner 66 clic Peugeot Partner Furgón y Patagónica Desde $660 Final x mes peugeot_408clic Peugeot 408 Allure + Tiptronic Precio de Lista $138.900 Bonificación Autofrance $13.000 Financiación Exclusiva Precio Autofrance $125.900 Anticipo $88.900 24 Ctas. x $2.669 peugeot_parthnerclic Peugeot Partner Confort 1.4 N Precio de Lista $77.400 Bonificación Autofrance $4.000 Financiación Exclusiva Precio Autofrance $73.400 Anticipo $27.400 36 Ctas. x $2.076 Y además, conocé las mejores ofertas de 0km, con descuentos exclusivos. Hace clic aquí
