Re: games/fortune translation fix
On Sun, Feb 03, 2019 at 01:13:18AM +0100, Ingo Schwarze wrote: > Hi Jason, > > oh well, these files are a mess, a random collection of funny > and not so funny stuff... I dislike this one, too, for several > reasons. > hey, don;t be so down on the fortune files! while i don;t neccessarily like your translation, i do defer to your knowledge of these matters (i did wave the don;t know latin flag upfront). so please go ahead and fix it - you'll be contributing to an important part of openbsd! jmc > 1. While "ad astra per aspera" sometimes occurs, the word order > "per aspera ad astra" is much more commonly used. It sounds > much better - not only because it respects the logical > chronological order, but even more so for metric reasons: > "per aspera ad astra" follows a loosely trochaic rhythm > " - | X- (x)-X- " while"ad astra per aspera" has no > discernible metric whatsoever: " - | X- | - X-- ". > > 2. It doesn't actually appear to be an antique or even medieval > latin proverb but merely a modern invention. > > 3. According to my latin dictionary, "ad astra" did occur in > antiquity, in a strongly metaphoric sense where "astra = heaven, > immortality, sphere and home of the gods" rather than "stars" - > though the only source cited there is Vergilius, Aeneis: > Macte nova virtute, puer, sic itur ad astra. > literal (hence somewhat misleading) translation: > Blessings on your young courage, boy; that's the way to the stars. > free translation, capturing the meaning and register better: > Go on and increase in valor, O boy! this is the path to immortality. > See e.g. https://en.wikiquote.org/wiki/Aeneid > Seneca also appears to use it in the context of a demi-god > (Hercules) interacting with the Olympians. > > So "ad astra" appears to be a rather unsual phrase, highly poetic, > suited to heroic legends about gods and super-human men interacting > directly with the greatest gods. > > 4. According to my latin dictionary, "asper" is a very common > adjective with a wide range of everyday concrete meanings: > rough, uneven, sharp, coarse, gruff, wild, disagreeable, > sorrowful, severe, rancorous, ... and more. > It was sometimes - but much less commonly, it appears - > used as a noun, though usually with a qualification in the > genitive, e.g. "aspera maris" = tempests (Tacitus). > When used alone as a noun, it appears to have a relatively > narrow, figurative, relatively mild meaning of "tribulations, > annoying trouble, misfortune"; translations like "hardship" or > "adversity" appear to exceed the severity of "asper(a)", > making it sound too much like serious emergency and distress. > > So a fitting translation of "per aspera ad astra", approximating > the meaning and stylistic register of both parts, might be > > "overcoming annoying problems to be elevated immortality" > > which sounds, yes, ridiculous. > > The word "aspiration" is definitely a blatant mistranslation. > > So if you want to keep the entry, i'd recommend > > Per aspera ad astra. (Through hardship to immortality.) > > because that is probably how it is commonly understood today, with > a weakened sense of "immortality" = "greatness, being remembered > for one's achievements after death", and it is also a compromise > not too far deviating from the actual meaning of the latin words, > even if sharpening "aspera" a bit and weakening "astra" somewhat > to smooth out content and and stylistic register. > > I think while the literal translation "to the stars" might work in > a heroic legend, it is quite misleading out of context and ought > to be fixed. > > Yours, > Ingo > > P.S. > I don't know why i looked at this so closely given my disdain for > these files - but from time to time, it appears i fail to sufficiently > tame my appetite for literature. > > > > i agree "aspiration" looks like a mistake. i suspect the intention > > was "asperity", which means harshness and rigour. there is a verb, > > asperate, but i think it's a bit obsolete. > > "Asperity" certainly matches the *adjective* "asper", but it matches > the *noun* "aspera" much less than "hardship" or "adversity" or > simply "trouble". > > > i'm a bit reluctant to just follow wikipedia blindly. i think the > > latin is pural, and "hardships" doesn;t sound awesome when plural. > > The grammatical form is unimportant for the translation in this > case. "aspara" (pl.) = "hardship, adversity" (sing.) is OK, just > like you can translate "glasses" (pl.) to "Brille" (german, sing.). > The idea in the Latin word is that it is plural because more than > one unfortunate element is required to cause hardship, but that > is already adequately expressed in the singular form "hardship". > > > also i prefer "by" to "through": since it's latin, a little > > archaicism is good. > > Not really. It is fake
Re: games/fortune translation fix
Hi Jason, oh well, these files are a mess, a random collection of funny and not so funny stuff... I dislike this one, too, for several reasons. 1. While "ad astra per aspera" sometimes occurs, the word order "per aspera ad astra" is much more commonly used. It sounds much better - not only because it respects the logical chronological order, but even more so for metric reasons: "per aspera ad astra" follows a loosely trochaic rhythm " - | X- (x)-X- " while"ad astra per aspera" has no discernible metric whatsoever: " - | X- | - X-- ". 2. It doesn't actually appear to be an antique or even medieval latin proverb but merely a modern invention. 3. According to my latin dictionary, "ad astra" did occur in antiquity, in a strongly metaphoric sense where "astra = heaven, immortality, sphere and home of the gods" rather than "stars" - though the only source cited there is Vergilius, Aeneis: Macte nova virtute, puer, sic itur ad astra. literal (hence somewhat misleading) translation: Blessings on your young courage, boy; that's the way to the stars. free translation, capturing the meaning and register better: Go on and increase in valor, O boy! this is the path to immortality. See e.g. https://en.wikiquote.org/wiki/Aeneid Seneca also appears to use it in the context of a demi-god (Hercules) interacting with the Olympians. So "ad astra" appears to be a rather unsual phrase, highly poetic, suited to heroic legends about gods and super-human men interacting directly with the greatest gods. 4. According to my latin dictionary, "asper" is a very common adjective with a wide range of everyday concrete meanings: rough, uneven, sharp, coarse, gruff, wild, disagreeable, sorrowful, severe, rancorous, ... and more. It was sometimes - but much less commonly, it appears - used as a noun, though usually with a qualification in the genitive, e.g. "aspera maris" = tempests (Tacitus). When used alone as a noun, it appears to have a relatively narrow, figurative, relatively mild meaning of "tribulations, annoying trouble, misfortune"; translations like "hardship" or "adversity" appear to exceed the severity of "asper(a)", making it sound too much like serious emergency and distress. So a fitting translation of "per aspera ad astra", approximating the meaning and stylistic register of both parts, might be "overcoming annoying problems to be elevated immortality" which sounds, yes, ridiculous. The word "aspiration" is definitely a blatant mistranslation. So if you want to keep the entry, i'd recommend Per aspera ad astra. (Through hardship to immortality.) because that is probably how it is commonly understood today, with a weakened sense of "immortality" = "greatness, being remembered for one's achievements after death", and it is also a compromise not too far deviating from the actual meaning of the latin words, even if sharpening "aspera" a bit and weakening "astra" somewhat to smooth out content and and stylistic register. I think while the literal translation "to the stars" might work in a heroic legend, it is quite misleading out of context and ought to be fixed. Yours, Ingo P.S. I don't know why i looked at this so closely given my disdain for these files - but from time to time, it appears i fail to sufficiently tame my appetite for literature. > i agree "aspiration" looks like a mistake. i suspect the intention > was "asperity", which means harshness and rigour. there is a verb, > asperate, but i think it's a bit obsolete. "Asperity" certainly matches the *adjective* "asper", but it matches the *noun* "aspera" much less than "hardship" or "adversity" or simply "trouble". > i'm a bit reluctant to just follow wikipedia blindly. i think the > latin is pural, and "hardships" doesn;t sound awesome when plural. The grammatical form is unimportant for the translation in this case. "aspara" (pl.) = "hardship, adversity" (sing.) is OK, just like you can translate "glasses" (pl.) to "Brille" (german, sing.). The idea in the Latin word is that it is plural because more than one unfortunate element is required to cause hardship, but that is already adequately expressed in the singular form "hardship". > also i prefer "by" to "through": since it's latin, a little > archaicism is good. Not really. It is fake latin, not a real proverb, but a modern invention. So it should sound natural and modern. > "adversity" would be easily understood and have the correct meaning > (i think). but the translation you recommend (by Finn) restructures > the phrase. i think it should begin "To the stars" (that's a minus > for wikipedia too). so "To the stars by adversity." You should really invert the order to improve the metric and follow chronologic order as well as the usual wording. > though i suspect "asperity" would have most of us reaching for our >
Re: games/fortune translation fix
On Sat, Feb 02, 2019 at 04:44:37PM -0500, Ted Unangst wrote: > Jason McIntyre wrote: > > though i suspect "asperity" would have most of us reaching for our > > dictionaries, it's not neccessarily a bad thing. it seems the > > best fit to me. > > That may be construed as the one going to the stars is the one with the > asperity, however. I think the intention is to describe overcoming adveristy, > not getting to the stars by being the adversity, no? > hi. your mail doesn;t give me much to go on, so i'm unsure how to reply. if you overcome adversity, then i guess you have asperity. can you give me something more to go on? jmc
Re: games/fortune translation fix
Jason McIntyre wrote: > though i suspect "asperity" would have most of us reaching for our > dictionaries, it's not neccessarily a bad thing. it seems the > best fit to me. That may be construed as the one going to the stars is the one with the asperity, however. I think the intention is to describe overcoming adveristy, not getting to the stars by being the adversity, no?
Re: games/fortune translation fix
On Sat, Feb 02, 2019 at 06:10:21PM +0100, Alessandro DE LAURENZIS wrote: > Dear developers, > > Currently the latin motto "Ad astra per aspera" is translated as "to the > stars by aspiration", which sounds weird. > > The literal translation from Wikipedia [1] would be "through hardships > to the stars", but here I'm proposing a rewording by A. J. Finn, in "The > Woman in the Window: A Novel" (cited in Wikipedia too), which I like > more: "Through adversity to the stars": > > [...] hi. i should state that i know very little of latin before going any further. i agree "aspiration" looks like a mistake. i suspect the intention was "asperity", which means harshness and rigour. there is a verb, asperate, but i think it's a bit obsolete. i'm a bit reluctant to just follow wikipedia blindly. i think the latin is pural, and "hardships" doesn;t sound awesome when plural. also i prefer "by" to "through": since it's latin, a little archaicism is good. "adversity" would be easily understood and have the correct meaning (i think). but the translation you recommend (by Finn) restructures the phrase. i think it should begin "To the stars" (that's a minus for wikipedia too). so "To the stars by adversity." though i suspect "asperity" would have most of us reaching for our dictionaries, it's not neccessarily a bad thing. it seems the best fit to me. jmc > > Index: games/fortune/datfiles/fortunes2 > > === > > RCS file: /cvs/src/games/fortune/datfiles/fortunes2,v > > retrieving revision 1.49 > > diff -u -p -u -p -r1.49 fortunes2 > > --- games/fortune/datfiles/fortunes225 Nov 2017 05:55:40 - 1.49 > > +++ games/fortune/datfiles/fortunes22 Feb 2019 16:50:16 - > > @@ -7694,7 +7694,7 @@ Assume true for N, prove for N+1: > > it is true for all N+1 floors. > > QED. > > % > > -Ad astra per aspera. (To the stars by aspiration.) > > +Ad astra per aspera. (Through adversity to the stars.) > > % > > Adde parvum parvo manus acervus erit. > > [Add little to little and there will be a big pile.] > [...] > > Just my 2 cents. > > [1] https://en.wikipedia.org/wiki/Per_aspera_ad_astra > > -- > Alessandro DE LAURENZIS > [mailto:jus...@atlantide.t28.net] > Web: http://www.atlantide.t28.net > LinkedIn: https://www.linkedin.com/in/delaurenzis/ >
games/fortune translation fix
Dear developers, Currently the latin motto "Ad astra per aspera" is translated as "to the stars by aspiration", which sounds weird. The literal translation from Wikipedia [1] would be "through hardships to the stars", but here I'm proposing a rewording by A. J. Finn, in "The Woman in the Window: A Novel" (cited in Wikipedia too), which I like more: "Through adversity to the stars": [...] Index: games/fortune/datfiles/fortunes2 === RCS file: /cvs/src/games/fortune/datfiles/fortunes2,v retrieving revision 1.49 diff -u -p -u -p -r1.49 fortunes2 --- games/fortune/datfiles/fortunes225 Nov 2017 05:55:40 - 1.49 +++ games/fortune/datfiles/fortunes22 Feb 2019 16:50:16 - @@ -7694,7 +7694,7 @@ Assume true for N, prove for N+1: it is true for all N+1 floors. QED. % -Ad astra per aspera. (To the stars by aspiration.) +Ad astra per aspera. (Through adversity to the stars.) % Adde parvum parvo manus acervus erit. [Add little to little and there will be a big pile.] [...] Just my 2 cents. [1] https://en.wikipedia.org/wiki/Per_aspera_ad_astra -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: https://www.linkedin.com/in/delaurenzis/
sparc64 exception handling fix
On SPARC the address of the call instruction is placed in %o7 and a
normal function return will jump to %o7 + 8, skipping the delay slot.
The diff below changes the low-level libunwind code to take this into
account. This way the addresses seen by the unwinder are as expected
and the unwinder can find the correct information in the various
tables.
ok?
Index: lib/libunwind/src/Registers.hpp
===
RCS file: /cvs/src/lib/libunwind/src/Registers.hpp,v
retrieving revision 1.4
diff -u -p -r1.4 Registers.hpp
--- lib/libunwind/src/Registers.hpp 21 Oct 2018 05:08:35 - 1.4
+++ lib/libunwind/src/Registers.hpp 2 Feb 2019 16:11:16 -
@@ -2648,8 +2648,8 @@ public:
uint64_t getSP() const { return _registers.__o[6] + 2047; }
void setSP(uint64_t value) { _registers.__o[6] = value - 2047; }
- uint64_t getIP() const { return _registers.__o[7]; }
- void setIP(uint64_t value) { _registers.__o[7] = value; }
+ uint64_t getIP() const { return _registers.__o[7] + 8; }
+ void setIP(uint64_t value) { _registers.__o[7] = value - 8; }
uint64_t getWCookie() const{ return _wcookie; }
private:
@@ -2702,7 +2702,7 @@ inline uint64_t Registers_sparc64::getRe
switch (regNum) {
case UNW_REG_IP:
-return _registers.__o[7];
+return _registers.__o[7] + 8;
case UNW_REG_SP:
return _registers.__o[6] + 2047;
}
@@ -2729,7 +2729,7 @@ inline void Registers_sparc64::setRegist
switch (regNum) {
case UNW_REG_IP:
-_registers.__o[7] = value;
+_registers.__o[7] = value - 8;
return;
case UNW_REG_SP:
_registers.__o[6] = value - 2047;
Index: lib/libunwind/src/UnwindRegistersRestore.S
===
RCS file: /cvs/src/lib/libunwind/src/UnwindRegistersRestore.S,v
retrieving revision 1.4
diff -u -p -r1.4 UnwindRegistersRestore.S
--- lib/libunwind/src/UnwindRegistersRestore.S 21 Oct 2018 05:08:35 -
1.4
+++ lib/libunwind/src/UnwindRegistersRestore.S 2 Feb 2019 16:11:16 -
@@ -669,7 +669,7 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
ldx [%o0 + 0xe8], %i5
ldx [%o0 + 0xf0], %i6
ldx [%o0 + 0xf8], %i7
- jmpl %o7, %g0
+ jmpl %o7 + 8, %g0
ldx [%o0 + 0x40], %o0
#elif defined(__mips__) && defined(_ABIO32)
binutils .eh_frame_hdr fixes
While investigating an exception handling issue reported by otto@ on
sparc64, I noticed that the .eh_frame_hdr section wasn't properly
populated in some cases. Turns out the code that parses the .eh_frame
section to populate .eh_frame_hdr has some deficiencies that make it
bail out. The diff below adds some fixes from upstream (before the
GPLv3 switch). With these fixes .eh_frame_hdr seems to be populated
correctly.
ok?
Index: gnu/usr.bin/binutils-2.17/bfd/elf-bfd.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/elf-bfd.h,v
retrieving revision 1.7
diff -u -p -r1.7 elf-bfd.h
--- gnu/usr.bin/binutils-2.17/bfd/elf-bfd.h 3 Dec 2018 02:59:51 -
1.7
+++ gnu/usr.bin/binutils-2.17/bfd/elf-bfd.h 2 Feb 2019 15:56:57 -
@@ -259,31 +259,6 @@ struct elf_link_loaded_list
};
/* Structures used by the eh_frame optimization code. */
-struct cie_header
-{
- unsigned int length;
- unsigned int id;
-};
-
-struct cie
-{
- struct cie_header hdr;
- unsigned char version;
- char augmentation[20];
- bfd_vma code_align;
- bfd_signed_vma data_align;
- bfd_vma ra_column;
- bfd_vma augmentation_size;
- struct elf_link_hash_entry *personality;
- unsigned char per_encoding;
- unsigned char lsda_encoding;
- unsigned char fde_encoding;
- unsigned char initial_insn_length;
- unsigned char make_relative;
- unsigned char make_lsda_relative;
- unsigned char initial_instructions[50];
-};
-
struct eh_cie_fde
{
/* For FDEs, this points to the CIE used. */
@@ -302,12 +277,12 @@ struct eh_cie_fde
unsigned int make_lsda_relative : 1;
unsigned int need_lsda_relative : 1;
unsigned int per_encoding_relative : 1;
+ unsigned int *set_loc;
};
struct eh_frame_sec_info
{
unsigned int count;
- unsigned int alloced;
struct eh_cie_fde entry[1];
};
@@ -317,11 +292,11 @@ struct eh_frame_array_ent
bfd_vma fde;
};
+struct htab;
+
struct eh_frame_hdr_info
{
- struct cie last_cie;
- asection *last_cie_sec;
- struct eh_cie_fde *last_cie_inf;
+ struct htab *cies;
asection *hdr_sec;
unsigned int fde_count, array_count;
struct eh_frame_array_ent *array;
Index: gnu/usr.bin/binutils-2.17/bfd/elf-eh-frame.c
===
RCS file: /cvs/src/gnu/usr.bin/binutils-2.17/bfd/elf-eh-frame.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 elf-eh-frame.c
--- gnu/usr.bin/binutils-2.17/bfd/elf-eh-frame.c24 Apr 2011 20:14:41
- 1.1.1.1
+++ gnu/usr.bin/binutils-2.17/bfd/elf-eh-frame.c2 Feb 2019 15:56:57
-
@@ -26,6 +26,30 @@
#define EH_FRAME_HDR_SIZE 8
+struct cie
+{
+ unsigned int length;
+ unsigned int hash;
+ unsigned char version;
+ char augmentation[20];
+ bfd_vma code_align;
+ bfd_signed_vma data_align;
+ bfd_vma ra_column;
+ bfd_vma augmentation_size;
+ struct elf_link_hash_entry *personality;
+ asection *output_sec;
+ struct eh_cie_fde *cie_inf;
+ unsigned char per_encoding;
+ unsigned char lsda_encoding;
+ unsigned char fde_encoding;
+ unsigned char initial_insn_length;
+ unsigned char make_relative;
+ unsigned char make_lsda_relative;
+ unsigned char initial_instructions[50];
+};
+
+
+
/* If *ITER hasn't reached END yet, read the next byte into *RESULT and
move onto the next byte. Return true on success. */
@@ -180,12 +204,16 @@ write_value (bfd *abfd, bfd_byte *buf, b
}
}
-/* Return zero if C1 and C2 CIEs can be merged. */
+/* Return one if C1 and C2 CIEs can be merged. */
-static
-int cie_compare (struct cie *c1, struct cie *c2)
+static int
+cie_eq (const void *e1, const void *e2)
{
- if (c1->hdr.length == c2->hdr.length
+ const struct cie *c1 = e1;
+ const struct cie *c2 = e2;
+
+ if (c1->hash == c2->hash
+ && c1->length == c2->length
&& c1->version == c2->version
&& strcmp (c1->augmentation, c2->augmentation) == 0
&& strcmp (c1->augmentation, "eh") != 0
@@ -194,6 +222,7 @@ int cie_compare (struct cie *c1, struct
&& c1->ra_column == c2->ra_column
&& c1->augmentation_size == c2->augmentation_size
&& c1->personality == c2->personality
+ && c1->output_sec == c2->output_sec
&& c1->per_encoding == c2->per_encoding
&& c1->lsda_encoding == c2->lsda_encoding
&& c1->fde_encoding == c2->fde_encoding
@@ -201,9 +230,38 @@ int cie_compare (struct cie *c1, struct
&& memcmp (c1->initial_instructions,
c2->initial_instructions,
c1->initial_insn_length) == 0)
-return 0;
+return 1;
- return 1;
+ return 0;
+}
+
+static hashval_t
+cie_hash (const void *e)
+{
+ const struct cie *c = e;
+ return c->hash;
+}
+
+static hashval_t
+cie_compute_hash (struct cie *c)
+{
+ hashval_t h = 0;
+ h = iterative_hash_object (c->length, h);
+ h = iterative_hash_object (c->version, h);
+ h = iterative_hash (c->augmentation, strlen (c->augmentation) + 1, h);
+ h =
Re: httpd.conf(5) man page
That explains by it is not documented and the somewhat awkward syntax. Will take care with future use cases. Thanks for the info! El sáb., 2 feb. 2019 a las 12:52, Hiltjo Posthuma () escribió: > > On Sat, Feb 02, 2019 at 12:20:03PM +0100, Daniel Gracia wrote: > > Hi there! > > > > httpdd FastCGI interface can connect seamlessly to a local TCP port, > > but this is not documented on the man page. > > > > Went to the source and found the syntax to be a little awkward (maybe > > a quick fix?). Anyway, allowed me running flask/flup/bottle pretty > > straightforward. > > > > Regards! > > > > Index: usr.sbin/httpd/httpd.conf.5 > > === > > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v > > retrieving revision 1.101 > > diff -u -p -u -p -r1.101 httpd.conf.5 > > --- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101 > > +++ usr.sbin/httpd/httpd.conf.5 2 Feb 2019 11:03:48 - > > @@ -278,12 +278,16 @@ will neither display nor generate a dire > > Enable FastCGI instead of serving files. > > The > > .Ar socket > > -is a local path name within the > > +can be a local path name within the > > .Xr chroot 2 > > root directory of > > .Xr httpd 8 > > -and defaults to > > -.Pa /run/slowcgi.sock . > > +(defaults to > > +.Pa /run/slowcgi.sock > > +). Starting with colon, > > +.Ar socket > > +can specify a port number that will connect to INADDR_LOOPBACK > > +address. > > .Pp > > The FastCGI handler will be given the following variables: > > .Pp > > > > Hi, > > Cool, I did not know httpd could do this. The commit (git mirror) says: > > " > commit 2204991274ff67f80cfd592f8470cdaca7a906e9 > Author: reyk > Date: Sat Aug 2 11:52:00 2014 + > > Allow to specify a FastCGI TCP socket on localhost (eg. :9000). Used > for debugging, you should prefer local UNIX sockets, but it helped to > find an issue that will be fixed with the next commit. > " > > CVS server_fci.c rev 1.9: > http://cvsweb.openbsd.org/src/usr.sbin/httpd/server_fcgi.c?rev=1.9=text/x-cvsweb-markup > > So maybe it was a debugging feature. > > -- > Kind regards, > Hiltjo
Re: httpd.conf(5) man page
On Sat, Feb 02, 2019 at 12:20:03PM +0100, Daniel Gracia wrote: > Hi there! > > httpdd FastCGI interface can connect seamlessly to a local TCP port, > but this is not documented on the man page. > > Went to the source and found the syntax to be a little awkward (maybe > a quick fix?). Anyway, allowed me running flask/flup/bottle pretty > straightforward. > > Regards! > > Index: usr.sbin/httpd/httpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v > retrieving revision 1.101 > diff -u -p -u -p -r1.101 httpd.conf.5 > --- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101 > +++ usr.sbin/httpd/httpd.conf.5 2 Feb 2019 11:03:48 - > @@ -278,12 +278,16 @@ will neither display nor generate a dire > Enable FastCGI instead of serving files. > The > .Ar socket > -is a local path name within the > +can be a local path name within the > .Xr chroot 2 > root directory of > .Xr httpd 8 > -and defaults to > -.Pa /run/slowcgi.sock . > +(defaults to > +.Pa /run/slowcgi.sock > +). Starting with colon, > +.Ar socket > +can specify a port number that will connect to INADDR_LOOPBACK > +address. > .Pp > The FastCGI handler will be given the following variables: > .Pp > Hi, Cool, I did not know httpd could do this. The commit (git mirror) says: " commit 2204991274ff67f80cfd592f8470cdaca7a906e9 Author: reyk Date: Sat Aug 2 11:52:00 2014 + Allow to specify a FastCGI TCP socket on localhost (eg. :9000). Used for debugging, you should prefer local UNIX sockets, but it helped to find an issue that will be fixed with the next commit. " CVS server_fci.c rev 1.9: http://cvsweb.openbsd.org/src/usr.sbin/httpd/server_fcgi.c?rev=1.9=text/x-cvsweb-markup So maybe it was a debugging feature. -- Kind regards, Hiltjo
httpd.conf(5) man page
Hi there! httpdd FastCGI interface can connect seamlessly to a local TCP port, but this is not documented on the man page. Went to the source and found the syntax to be a little awkward (maybe a quick fix?). Anyway, allowed me running flask/flup/bottle pretty straightforward. Regards! Index: usr.sbin/httpd/httpd.conf.5 === RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v retrieving revision 1.101 diff -u -p -u -p -r1.101 httpd.conf.5 --- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101 +++ usr.sbin/httpd/httpd.conf.5 2 Feb 2019 11:03:48 - @@ -278,12 +278,16 @@ will neither display nor generate a dire Enable FastCGI instead of serving files. The .Ar socket -is a local path name within the +can be a local path name within the .Xr chroot 2 root directory of .Xr httpd 8 -and defaults to -.Pa /run/slowcgi.sock . +(defaults to +.Pa /run/slowcgi.sock +). Starting with colon, +.Ar socket +can specify a port number that will connect to INADDR_LOOPBACK +address. .Pp The FastCGI handler will be given the following variables: .Pp
Re: pfctl -ss: show rt_addr
On 2019/02/02 19:26, YASUOKA Masahiko wrote:
> On Fri, 1 Feb 2019 11:13:01 +
> Stuart Henderson wrote:
> > On 2019/02/01 18:09, YASUOKA Masahiko wrote:
> >> Hi,
> >>
> >> I often use "route-to" for DSR or balancing routes. It seems there is
> >> no way to know which route is selected for the pf state.
> >>
> >> The diff following makes "pfctl -ss" show the route address with
> >> square brackets if any.
> >>
> >> example:
> >>
> >> all tcp 10.0.0.101:8080 [10.0.0.12] <- 10.1.0.100:45482
> >> ESTABLISHED:ESTABLISHED
> >>
> >> all tcp 10.0.0.165:35691 -> 192.168.0.156:22 [10.0.0.2]
> >> ESTABLISHED:ESTABLISHED
> >>
> >> ok? comment?
> >
> > I'd like to have this information too, but [] are quite heavily used
> > in the output format already, making it a bit hard to grep or pipe
> > through cut -d'[' to extract certain parts. What do you/anyone else
> > think of using { } for this instead?
>
> Using { } is also fine for me.
Thanks, OK sthen@
> Index: sbin/pfctl/pf_print_state.c
> ===
> RCS file: /disk/cvs/openbsd/src/sbin/pfctl/pf_print_state.c,v
> retrieving revision 1.68
> diff -u -p -r1.68 pf_print_state.c
> --- sbin/pfctl/pf_print_state.c 7 Sep 2018 10:29:22 - 1.68
> +++ sbin/pfctl/pf_print_state.c 2 Feb 2019 10:21:24 -
> @@ -241,6 +241,11 @@ print_state(struct pfsync_state *s, int
> sk->rdomain, pn, opts);
> printf(")");
> }
> + if (s->direction == PF_IN && !PF_AZERO(>rt_addr, sk->af)) {
> + printf(" {");
> + print_addr_str(sk->af, >rt_addr);
> + printf("}");
> + }
> if (s->direction == PF_OUT || (afto && s->direction == PF_IN))
> printf(" -> ");
> else
> @@ -254,6 +259,11 @@ print_state(struct pfsync_state *s, int
> print_host(>addr[idx], sk->port[idx], sk->af,
> sk->rdomain, pn, opts);
> printf(")");
> + }
> + if (s->direction == PF_OUT && !PF_AZERO(>rt_addr, nk->af)) {
> + printf(" {");
> + print_addr_str(nk->af, >rt_addr);
> + printf("}");
> }
>
> printf("");
Re: pfctl -ss: show rt_addr
On Fri, 1 Feb 2019 11:13:01 +
Stuart Henderson wrote:
> On 2019/02/01 18:09, YASUOKA Masahiko wrote:
>> Hi,
>>
>> I often use "route-to" for DSR or balancing routes. It seems there is
>> no way to know which route is selected for the pf state.
>>
>> The diff following makes "pfctl -ss" show the route address with
>> square brackets if any.
>>
>> example:
>>
>> all tcp 10.0.0.101:8080 [10.0.0.12] <- 10.1.0.100:45482
>> ESTABLISHED:ESTABLISHED
>>
>> all tcp 10.0.0.165:35691 -> 192.168.0.156:22 [10.0.0.2]
>> ESTABLISHED:ESTABLISHED
>>
>> ok? comment?
>
> I'd like to have this information too, but [] are quite heavily used
> in the output format already, making it a bit hard to grep or pipe
> through cut -d'[' to extract certain parts. What do you/anyone else
> think of using { } for this instead?
Using { } is also fine for me.
Index: sbin/pfctl/pf_print_state.c
===
RCS file: /disk/cvs/openbsd/src/sbin/pfctl/pf_print_state.c,v
retrieving revision 1.68
diff -u -p -r1.68 pf_print_state.c
--- sbin/pfctl/pf_print_state.c 7 Sep 2018 10:29:22 - 1.68
+++ sbin/pfctl/pf_print_state.c 2 Feb 2019 10:21:24 -
@@ -241,6 +241,11 @@ print_state(struct pfsync_state *s, int
sk->rdomain, pn, opts);
printf(")");
}
+ if (s->direction == PF_IN && !PF_AZERO(>rt_addr, sk->af)) {
+ printf(" {");
+ print_addr_str(sk->af, >rt_addr);
+ printf("}");
+ }
if (s->direction == PF_OUT || (afto && s->direction == PF_IN))
printf(" -> ");
else
@@ -254,6 +259,11 @@ print_state(struct pfsync_state *s, int
print_host(>addr[idx], sk->port[idx], sk->af,
sk->rdomain, pn, opts);
printf(")");
+ }
+ if (s->direction == PF_OUT && !PF_AZERO(>rt_addr, nk->af)) {
+ printf(" {");
+ print_addr_str(nk->af, >rt_addr);
+ printf("}");
}
printf("");
Re: fork rt_ifa_{add,del} for mpls local input routes
On Fri, Feb 01, 2019 at 02:40:17PM -0200, Martin Pieuchot wrote:
> On 31/01/19(Thu) 13:31, David Gwynne wrote:
> > On Wed, Jan 30, 2019 at 11:54:45AM -0200, Martin Pieuchot wrote:
> > > On 30/01/19(Wed) 11:48, David Gwynne wrote:
> > > > mpls uses AF_MPLS routes with RTF_LOCAL set on them to know which tags
> > > > are used as input for the mpe and mpw interfaces. setting this up
> > > > currently goes through rt_ifa_add, but that has a couple of features
> > > > that are undesirable for mpls.
> > > >
> > > > Firstly, rt_ifa_add unconditionally sets RTF_MPATH on the routes it
> > > > adds, which means multiple mpe and mpw interfaces can "own" the same
> > > > input tag. mpe tries to work around this by maintaining a global list of
> > > > mpe interfaces, and iterates over them when a new label is added. That's
> > > > ok (sort of) for mpe, but it doesnt take the tags used by mpw into
> > > > account.
> > >
> > > I don't understand how this work, where are these 'tag' and 'label'
> > > stored? What do you mean with "'own' the same input tag"?
> >
> > I'm using tag and label interchangably here, but it refers to the number
> > that appears in the MPLS shim header on the wire. Each label is supposed
> > to represent a single "forwarding equivalence class", ie, each MPLS label
> > is only supposed to do one thing. When we're talkign about mpe and mpw
> > input, we're talking about configuring each interface with a local
> > MPLS label. Packets sent to the label on the local machine should
> > end up as packets coming in on an mpe or mpw interface.
> >
> > Right now mpw and mpe use rt_ifa_add() to claim ownership of a local
> > tag. Once something is using a tag, nothing else should be able to add
> > an entry to the mpls rtable with that same tag. Because rt_ifa_add()
> > adds RTF_MPATH unconditionally, it is possible to add two things with
> > the same label to the mpls rtable.
> >
> > > What is the current 'gateway' value of MPLS RTF_LOCAL routes?
> >
> > It's the struct sockaddr_dl *if_sadl in struct ifnet.
> >
> > > > Secondly, I'd like to start pulling apart the restriction on the use of
> > > > mpls only in rdomain 1. rt_ifa_add doesn't help this situation because
> > > > it assumes that we're adding a route inside the rdomain the interface is
> > > > in, rather than the one it tunnels in. Changing this assumption means
> > > > forking rt_ifa_add, and oh look, that's what I've started here.
> > >
> > > I'm afraid of adding new rtrequest(9) calls, especially with new error
> > > conditions. Why can't you add the rdomain of the tunnel?
> >
> > ifp->if_rdomain refers to the rdomain of the traffic going over an
> > interface. For tunnels it is the rdomain of packets inside the
> > tunnel. Another way of saying it is that a tunnel provides an overlay
> > on top of an underlay network, and ifp->if_rdomain is the rdomain
> > of the overlay traffic.
> >
> > When we're adding the mpls rtable entries we're specifying connectivity
> > outside the tunnel, aka routes in the network underlay. Currently
> > rt_ifa_{add,del} force anything with RTF_MPLS into rdomain 0 despite
> > what the overlay is, and despite where you might want to run the
> > underlay. One of the configurations claudio@ and I talked about for
> > the firewalls at work was running MPLS in rdomain 1 and leaving our
> > current config running in rdomain 0. This model is not currently
> > possible with RTF_MPLS routes forced to the mpls rtable in rdomain 0.
>
> I don't understand how you're going to select the rtable. It will be
> different than the MPLS interface's rdomain, right?
The tunnel interfaces have SIOCSLIFPHYRTABLE and SIOCGLIFPHYRTABLE. I
was going to reuse that for specifying the rdomain MPLS "tunnels" in.
> The current codes for !AF_MPLS routes use the current rdomain because
> that's where the L2 entries live in our kernel.
Well, IP things still add their own l2 to the interfaces inside the
rdomain just like now. My current theory is that MPLS using it to add
the input tag was an elegant^Wconvenient hack since you want to do
mostly the same thing as IP, just outside the current rdomain. The hack
assumed MPLS could only exist in rdomain 0, hence the hardcoded values.
>
> > > If all you need is remove RTF_MPATH, then do so :)
> > >
> > > We can add it to all rt_ifa_add(9) calls to be explicit!
> >
> > That won't solve the rdomain thing though.
> >
> > How about making rt_ifa_{add,del} as wrappers around the thing that
> > let's you not specify RTF_MPATH, and explicitly configure the rdomain?
> > This effectively replaces rt_ifa_{add,del} with rt_ifa_{add,del}_rdomain
> > respectively, but provides the old names as wrappers on the new one.
>
> If all you're after is specifying these two parameters lets add them to
> the existing rt_ifa_add() call :o) We need fewer APIs!
k.
Let's do that in two steps. The diff below removes the implicit
RTF_MPATH in rt_ifa_add() and has the callers set it explicitly.
A second diff
