Re: Strange route entry from China
Op 14 mei 2014 om 07:48 heeft Johan Beisser het volgende
geschreven:
> On Tue, May 13, 2014 at 10:31 PM, Johan Ryberg wrote:
>> Yes, it's related to a SSH brute force attack.
>>
>> I have just never seen the the "client" IP in the routing table before. My
>> IP does not exist in the routing table when I SSH to the host.
>
> The IP shouldn't be there, at all. But, according to the route flags
> ('D' in this case), it's in there due to a redirect.
>
>> I have a hard time to understand the mechanism that added the IP to the
>> table.
>>
>> Is this something that can be explained?
>
> My assumption is there was an ICMP redirect that added the IP to your table.
>
> Check to see if you're accepting redirects. By default, OpenBSD has them as
> off.
There are more reasons dynamic route entries are createf. For example to record
results of mtu path discovery.
-Otto
Re: Strange route entry from China
On Tue, May 13, 2014 at 11:57 PM, Otto Moerbeek wrote: > > Op 14 mei 2014 om 07:48 heeft Johan Beisser het volgende > geschreven: > > > There are more reasons dynamic route entries are createf. For example to > record results of mtu path discovery. That implies a successful TCP connection to the router itself, doesn't it?
Re: cron reload
Hello, Yes, but you will be awoken even if you didn't poke cron via socket because of the timeout, and cron will check anyway for updates. 2014-05-14 6:54 GMT+02:00 Philip Guenther : > On Sun, May 11, 2014 at 10:34 PM, Tomek WaÅaszek wrote: >> >> I'm trying to understand the reason of using unix socket to poke cron >> daemon via crontab. If we would remove this feature from the cron then >> the functionality >> will be the same, I mean the cron would update the database because >> modification time of the SPOOL DIR will be different. Cron will also get >> the new data even when we delete the /var/cron/tabs/.sock. >> >> This maybe is a silly question but I dont quite get the idea of having >> unix >> socket in cron for reload. >> > > Why poll when you get woken only when needed instead? > > > Philip Guenther > > -- Pozdrawiam Tomasz WaÅaszek
Re: Strange route entry from China
On 14 May 2014 08:20, "Johan Beisser" wrote: > > On Tue, May 13, 2014 at 11:57 PM, Otto Moerbeek wrote: > > > > Op 14 mei 2014 om 07:48 heeft Johan Beisser het volgende geschreven: > > > > > > > There are more reasons dynamic route entries are createf. For example to record results of mtu path discovery. > > That implies a successful TCP connection to the router itself, doesn't it? > Sure. But connecting to port 22 in order to fail to auth is a successful TCP connection. Kevin
Re: Strange route entry from China
On Wed, May 14, 2014 at 12:40 AM, Kevin Lyda wrote: > > On 14 May 2014 08:20, "Johan Beisser" wrote: >> >> On Tue, May 13, 2014 at 11:57 PM, Otto Moerbeek wrote: >> > >> > Op 14 mei 2014 om 07:48 heeft Johan Beisser het >> > volgende geschreven: >> > >> > There are more reasons dynamic route entries are createf. For example to >> > record results of mtu path discovery. >> >> That implies a successful TCP connection to the router itself, doesn't it? >> > > Sure. But connecting to port 22 in order to fail to auth is a successful TCP > connection. Yes. Path MTU implies the connection is held open for larger packets than just during the handshake and SSH negotiation. Or am I misunderstanding when MTU is negotiated?
Re: cron reload
On Wed, May 14, 2014 at 12:31 AM, Tomek WaÅaszek wrote: > > Yes, but you will be awoken even if you didn't poke cron via socket > because of the timeout, and cron will check anyway for updates. > 1) don't top post 2) your sentence isn't clear enough for me to figure what you're claiming would work or why. 3) since you're apparently claiming that the unix-domain socket bits are unnecessary, what testing of this have you done? Philip Guenther
Re: cron reload
2014-05-14 10:00 GMT+02:00 Philip Guenther : > On Wed, May 14, 2014 at 12:31 AM, Tomek WaÅaszek wrote: >> >> Yes, but you will be awoken even if you didn't poke cron via socket >> because of the timeout, and cron will check anyway for updates. >> > > 1) don't top post > 2) your sentence isn't clear enough for me to figure what you're claiming > would work or why. > 3) since you're apparently claiming that the unix-domain socket bits are > unnecessary, what testing of this have you done? > > > Philip Guenther > > Sorry for the top post I'm just trying to understand why there is a unix-domain socket for reloading the cron if without the socket (rm /var/cron/tabs/.sock) cron will reload new jobs.
Re: firefox-26.0p1.tgz signature verification FAIL
On Tue, May 13, 2014 at 06:42:53PM +, Alexej wrote: > Greetings gentlemen, > > Downloaded and installed install55.iso, SHA256 was verified successfuly. > > Downloaded firefox-26.0p1.tgz from Canada (Alberta) mirror site along with > SHA256 files. > > /pub/OpenBSD/5.5/packages/amd64/SHA256 > /pub/OpenBSD/5.5/packages/amd64/SHA256.sig > /pub/OpenBSD/5.5/packages/amd64/firefox-26.0p1.tgz > > Then performed a check and got a result: > > Signature Verified > firefox-26.0p1.tgz: FAIL Yes, it's okay. Don't perform that check. I don't even understand why someone signed SHA256 in the package directory. All packages have embedded signatures, and pkg_add checks them directly. If you're using a 5.5 system, just pkg_add that package. If there's a corruption, pkg_add will tell you. pkg_add from 5.5 *won't* install unsigned packages unless you're using specific options (-Dunsigned).
wildcards for principals when generating ssh certificate
Hi, is it possible to have a wildcard in principals when generating user certificate? ssh-keygen(1) states: ssh-keygen -s ca_key -I key_id -h -n host.domain user_key.pub I mean something like this: ssh-keygen -s ca_key -I key_id -h -n webapp*.domain user_key.pub Thanks for clarification. j.
Is there any chance to implement switch to turn off for example PCI-Express devices?
Hello I have in laptop many devices that I don't use. For example DVD writer. But my greates problem is the unability to turn off under OpenBSD Nvidia GPU. Unfortunately I have Optimus laptop, so I don't have normal, independent hardware multiplexer. I have Intel and Nvidia GPUs, and Intel GPU is proxy for Nvidia GPU. I don't use Nvidia GPU under Linux and it is fine. However under OpenBSD I even can't turn off Nvidia GPU despite that GPU is not usable due to lack of drivers in OpenBSD for this GPU. Intel GPU is fine for me for Linux and OpenBSD tasks (I use Nvidia GPU for Autodesk Inventor in Windows). But Nvidia GPU is heating my laptop despite it isn't used by OpenBSD. It is significant change in temperature, under Linux and Windows (lightweight tasks) I have about 42 Celsius degrees (°C) and under OpenBSD default configuration when it is idle it is 67 Celsius degrees (°C), when I switched frequency of CPU to lowest possible by apmd it is still about 63 Celsius degrees (°C).! I think this can reduce lifetime of my laptop. I think that in OpenBSD there is currently no way to disable particular device, but as I understand PCI-Express has power-management capabilities and can turn off device. Is there any chance that in future version of OpenBSD will be implemented switch to turn off particular device by advanced users via sysctl or I don't know, /dev directory? Something like bbswitch under Linux. In any case there is output of my dmesg: http://daemonforums.org/showpost.php?p=50519&postcount=98
Re: firefox-26.0p1.tgz signature verification FAIL
On 2014-05-14, Marc Espie wrote: > On Tue, May 13, 2014 at 06:42:53PM +, Alexej wrote: >> Greetings gentlemen, >> >> Downloaded and installed install55.iso, SHA256 was verified successfuly. >> >> Downloaded firefox-26.0p1.tgz from Canada (Alberta) mirror site along with >> SHA256 files. >> >> /pub/OpenBSD/5.5/packages/amd64/SHA256 >> /pub/OpenBSD/5.5/packages/amd64/SHA256.sig >> /pub/OpenBSD/5.5/packages/amd64/firefox-26.0p1.tgz >> >> Then performed a check and got a result: >> >> Signature Verified >> firefox-26.0p1.tgz: FAIL When reporting such a problem, please include the command you have run... This problem excepted (which I think is with pkg_sign -C), there's something wrong going on with signify -C; check out the timings: $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig moo-1.3p1.tgz Signature Verified moo-1.3p1.tgz: FAIL 65.83 real31.48 user34.32 sys 40304 maximum resident set size 0 average shared memory size 0 average unshared data size 0 average unshared stack size 11571228 minor page faults 0 major page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 235 voluntary context switches 122 involuntary context switches "signature verified" is returned immediately, FAIL takes a whole minute. $ \time -l sha256 -C SHA256.sig moo-1.3p1.tgz (SHA256) moo-1.3p1.tgz: OK 0.00 real 0.01 user 0.00 sys 588 maximum resident set size 0 average shared memory size 0 average unshared data size 0 average unshared stack size 273 minor page faults 0 major page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 0 voluntary context switches 0 involuntary context switches
Re: firefox-26.0p1.tgz signature verification FAIL
On 2014-05-14, Stuart Henderson wrote: > On 2014-05-14, Marc Espie wrote: >> On Tue, May 13, 2014 at 06:42:53PM +, Alexej wrote: >>> Greetings gentlemen, >>> >>> Downloaded and installed install55.iso, SHA256 was verified successfuly. >>> >>> Downloaded firefox-26.0p1.tgz from Canada (Alberta) mirror site along with >>> SHA256 files. >>> >>> /pub/OpenBSD/5.5/packages/amd64/SHA256 >>> /pub/OpenBSD/5.5/packages/amd64/SHA256.sig >>> /pub/OpenBSD/5.5/packages/amd64/firefox-26.0p1.tgz >>> >>> Then performed a check and got a result: >>> >>> Signature Verified >>> firefox-26.0p1.tgz: FAIL > > When reporting such a problem, please include the command you have run... > > This problem excepted (which I think is with pkg_sign -C), there's something I'm wrong here, pkg_sign -C is ok. > wrong going on with signify -C; check out the timings: > > $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig > moo-1.3p1.tgz > Signature Verified > moo-1.3p1.tgz: FAIL >65.83 real31.48 user34.32 sys > 40304 maximum resident set size > 0 average shared memory size > 0 average unshared data size > 0 average unshared stack size > 11571228 minor page faults > 0 major page faults > 0 swaps > 0 block input operations > 0 block output operations > 0 messages sent > 0 messages received > 0 signals received >235 voluntary context switches >122 involuntary context switches > > "signature verified" is returned immediately, FAIL takes a whole minute. > > $ \time -l sha256 -C SHA256.sig moo-1.3p1.tgz > (SHA256) moo-1.3p1.tgz: OK ... as evidenced by this being "OK". > 0.00 real 0.01 user 0.00 sys >588 maximum resident set size > 0 average shared memory size > 0 average unshared data size > 0 average unshared stack size >273 minor page faults > 0 major page faults > 0 swaps > 0 block input operations > 0 block output operations > 0 messages sent > 0 messages received > 0 signals received > 0 voluntary context switches > 0 involuntary context switches
Re: firefox-26.0p1.tgz signature verification FAIL
On 2014-05-14, Stuart Henderson wrote: > On 2014-05-14, Stuart Henderson wrote: >> On 2014-05-14, Marc Espie wrote: >>> On Tue, May 13, 2014 at 06:42:53PM +, Alexej wrote: Greetings gentlemen, Downloaded and installed install55.iso, SHA256 was verified successfuly. Downloaded firefox-26.0p1.tgz from Canada (Alberta) mirror site along with SHA256 files. /pub/OpenBSD/5.5/packages/amd64/SHA256 /pub/OpenBSD/5.5/packages/amd64/SHA256.sig /pub/OpenBSD/5.5/packages/amd64/firefox-26.0p1.tgz Then performed a check and got a result: Signature Verified firefox-26.0p1.tgz: FAIL >> >> When reporting such a problem, please include the command you have run... >> >> This problem excepted (which I think is with pkg_sign -C), there's something > > I'm wrong here, pkg_sign -C is ok. ... but doesn't provide what signify -C is looking for, specifically signify -C wants a base16 hash, the SHA256 file in the package directory uses base64. So, correct use of this file at present: $ signify -V -p /etc/signify/openbsd-55-pkg.pub -m SHA256 Signature Verified $ sha256 -C SHA256 moo-1.3p1.tgz Though I agree with Marc's comment to just use the embedded signature in the packages for verification. >> wrong going on with signify -C; check out the timings: >> >> $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig >> moo-1.3p1.tgz >> Signature Verified >> moo-1.3p1.tgz: FAIL >>65.83 real31.48 user34.32 sys This was due to malloc flags 'S' or more specifically the 'G' (guard pages) component of this. (yes, from 0.06s to 65.83s).
Re: firefox-26.0p1.tgz signature verification FAIL
On Wed, May 14, 2014 at 12:44, Stuart Henderson wrote: >>> $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig > moo-1.3p1.tgz >>> Signature Verified >>> moo-1.3p1.tgz: FAIL >>>65.83 real31.48 user34.32 sys > > This was due to malloc flags 'S' or more specifically the 'G' (guard > pages) component of this. (yes, from 0.06s to 65.83s). There is a preposterously inefficient realloc loop used to parse SHA256 files. As long as it's only checking the base checksums, it's ok. Really, the feature was only added to make checking bsd.rd easier when upgrading. It won't be hard to fix, but as also noted, the ports SHA256 format isn't acceptable either. Now I have two problems...
Re: firefox-26.0p1.tgz signature verification FAIL
On 2014/05/14 11:21, Ted Unangst wrote: > On Wed, May 14, 2014 at 12:44, Stuart Henderson wrote: > >>> $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig > > moo-1.3p1.tgz > >>> Signature Verified > >>> moo-1.3p1.tgz: FAIL > >>>65.83 real31.48 user34.32 sys > > > > This was due to malloc flags 'S' or more specifically the 'G' (guard > > pages) component of this. (yes, from 0.06s to 65.83s). > > There is a preposterously inefficient realloc loop used to parse > SHA256 files. As long as it's only checking the base checksums, it's > ok. Really, the feature was only added to make checking bsd.rd easier > when upgrading. > > It won't be hard to fix, but as also noted, the ports SHA256 format > isn't acceptable either. Now I have two problems... As so often, /bin/rm may well be the answer :-)
Re: firefox-26.0p1.tgz signature verification FAIL
On 14 May 2014 11:26, Stuart Henderson wrote: > On 2014/05/14 11:21, Ted Unangst wrote: >> On Wed, May 14, 2014 at 12:44, Stuart Henderson wrote: >> >>> $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig >> > moo-1.3p1.tgz >> >>> Signature Verified >> >>> moo-1.3p1.tgz: FAIL >> >>>65.83 real31.48 user34.32 sys >> > >> > This was due to malloc flags 'S' or more specifically the 'G' (guard >> > pages) component of this. (yes, from 0.06s to 65.83s). >> >> There is a preposterously inefficient realloc loop used to parse >> SHA256 files. As long as it's only checking the base checksums, it's >> ok. Really, the feature was only added to make checking bsd.rd easier >> when upgrading. >> >> It won't be hard to fix, but as also noted, the ports SHA256 format >> isn't acceptable either. Now I have two problems... > > As so often, /bin/rm may well be the answer :-) > If only /bin wasn't full we could add a link /bin/tedu -> /bin/rm. Ken
Re: firefox-26.0p1.tgz signature verification FAIL
On Wed, May 14, 2014 at 11:21:43AM -0400, Ted Unangst wrote: > On Wed, May 14, 2014 at 12:44, Stuart Henderson wrote: > >>> $ \time -l signify -C -p /etc/signify/openbsd-55-pkg.pub -x SHA256.sig > > moo-1.3p1.tgz > >>> Signature Verified > >>> moo-1.3p1.tgz: FAIL > >>>65.83 real31.48 user34.32 sys > > > > This was due to malloc flags 'S' or more specifically the 'G' (guard > > pages) component of this. (yes, from 0.06s to 65.83s). > > There is a preposterously inefficient realloc loop used to parse > SHA256 files. As long as it's only checking the base checksums, it's > ok. Really, the feature was only added to make checking bsd.rd easier > when upgrading. > > It won't be hard to fix, but as also noted, the ports SHA256 format > isn't acceptable either. Now I have two problems... There's no point in providing SHA256.sig for packages. For one thing, it goes out of synch rather easily. For another thing, it's redundant with the package signatures themselves. THAT SHA256 file exists only to make it easier to check that a transfer went out okay. It's not there to protect against any kind of malice... (Ironically, signify produces base64 signatures, but doesn't grok base64 sha256 checksums... may I lol ?) Doing any kind of check as to the integrity of the package repository would be a ways more complicated problem... we're getting close to the certificate revocation problem. That way lies madness.
Re: firefox-26.0p1.tgz signature verification FAIL
On Wed, May 14, 2014 at 17:55, Marc Espie wrote: > There's no point in providing SHA256.sig for packages. For one thing, it > goes out of synch rather easily. For another thing, it's redundant with > the package signatures themselves. THAT SHA256 file exists only to make it > easier to check that a transfer went out okay. It's not there to protect > against any kind of malice... I'm inclined to say that if something looks like it could be used to protect against malice, we should sign it. Or not provide it. Providing a mix of signed and unsigned SHA256 files would be a dangerous inconsistency in my mind.
Re: firefox-26.0p1.tgz signature verification FAIL
On 2014-05-14 12:09, Ted Unangst wrote: Providing a mix of signed and unsigned SHA256 files would be a dangerous inconsistency in my mind. As an ordinary user, I can tell the difference between a file named "SHA256" and a file named "SHA256.sig". It's very easy when both files are included together with filesets. Only have one of these files, with packages, may introduce confusion among us users.
getaddrinfo(3) & chroot(2) with root
Hello all,
I am burning my last neurons with a behavior I can't explain. I wonder
why getaddrinfo() fails when called after chroot() with root user.
I have this piece of code :
/*--- test.c ---*/
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct addrinfo *ai_out;
struct passwd *pw;
int error;
pw = getpwnam("_bgpd");
error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
if (error)
printf("getaddrinfo() failed\n");
else printf("getaddrinfo() succeed\n");
chroot(pw->pw_dir);
chdir("/");
error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
if (error)
printf("getaddrinfo() failed\n");
else printf("getaddrinfo() succeed\n");
return 0;
}
/*--- test.c ---*/
$ ./a.out
getaddrinfo() succeed
getaddrinfo() succeed
# ./a.out
getaddrinfo() succeed
getaddrinfo() succeed
Everything is good. Now if I compile :
/*--- test.c ---*/
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct addrinfo *ai_out;
struct passwd *pw;
int error;
pw = getpwnam("_bgpd");
error = 0
if (error)
printf("getaddrinfo() failed\n");
else printf("getaddrinfo() succeed\n");
chroot(pw->pw_dir);
error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
if (error)
printf("getaddrinfo() failed\n");
else printf("getaddrinfo() succeed\n");
return 0;
}
/*--- test.c ---*/
$ ./a.out
getaddrinfo() succeed
getaddrinfo() succeed
# ./a.out
getaddrinfo() succeed
getaddrinfo() failed
If this an expected behavior, what would be the preferred way to resolve
a name from a chrooted process ? I am extending OpenBGPd and I need to
resolve domain names and connect to a service (no BGP protocol). I am
currently using the "session" process to handle the connection part but
I am stuck on name resolution for now.
Thank you in advance,
Denis
Re: getaddrinfo(3) & chroot(2) with root
On 05/14/14 18:57, Denis Fondras wrote:
> Hello all,
>
> I am burning my last neurons with a behavior I can't explain. I wonder
> why getaddrinfo() fails when called after chroot() with root user.
>
>
> I have this piece of code :
>
> /*--- test.c ---*/
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> struct addrinfo *ai_out;
> struct passwd *pw;
> int error;
>
> pw = getpwnam("_bgpd");
>
> error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> chroot(pw->pw_dir);
> chdir("/");
>
> error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> return 0;
> }
> /*--- test.c ---*/
>
> $ ./a.out
> getaddrinfo() succeed
> getaddrinfo() succeed
>
> # ./a.out
> getaddrinfo() succeed
> getaddrinfo() succeed
>
>
>
>
> Everything is good. Now if I compile :
>
> /*--- test.c ---*/
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> struct addrinfo *ai_out;
> struct passwd *pw;
> int error;
>
> pw = getpwnam("_bgpd");
>
> error = 0
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> chroot(pw->pw_dir);
>
> error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> return 0;
> }
> /*--- test.c ---*/
>
> $ ./a.out
> getaddrinfo() succeed
> getaddrinfo() succeed
>
> # ./a.out
> getaddrinfo() succeed
> getaddrinfo() failed
>
>
>
> If this an expected behavior, what would be the preferred way to resolve
> a name from a chrooted process ? I am extending OpenBGPd and I need to
> resolve domain names and connect to a service (no BGP protocol). I am
> currently using the "session" process to handle the connection part but
> I am stuck on name resolution for now.
>
> Thank you in advance,
> Denis
>
I wonder if you're using the wrong function. There is gethostbyname for
forward lookups?
Regards,
-peter
Re: getaddrinfo(3) & chroot(2) with root
On Wed, May 14, 2014 at 18:57, Denis Fondras wrote: > Hello all, > > I am burning my last neurons with a behavior I can't explain. I wonder > why getaddrinfo() fails when called after chroot() with root user. After chroot, /etc/resolv.conf is no longer available. > If this an expected behavior, what would be the preferred way to resolve > a name from a chrooted process ? I am extending OpenBGPd and I need to > resolve domain names and connect to a service (no BGP protocol). I am > currently using the "session" process to handle the connection part but > I am stuck on name resolution for now. Other daemons like ntpd have a helper process that runs outside chroot and does all of the DNS resolution for them.
Re: getaddrinfo(3) & chroot(2) with root
Le 14/05/2014 19:14, Peter J. Philipp a écrit : > > I wonder if you're using the wrong function. There is gethostbyname for > forward lookups? > I read it was deprecated. Denis
Re: getaddrinfo(3) & chroot(2) with root
2014-05-14 20:57 GMT+04:00 Denis Fondras :
> Hello all,
>
> I am burning my last neurons with a behavior I can't explain. I wonder
> why getaddrinfo() fails when called after chroot() with root user.
>
>
> I have this piece of code :
>
> /*--- test.c ---*/
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> struct addrinfo *ai_out;
> struct passwd *pw;
> int error;
>
> pw = getpwnam("_bgpd");
>
> error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> chroot(pw->pw_dir);
> chdir("/");
>
> error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> return 0;
> }
> /*--- test.c ---*/
>
> $ ./a.out
> getaddrinfo() succeed
> getaddrinfo() succeed
>
> # ./a.out
> getaddrinfo() succeed
> getaddrinfo() succeed
>
>
>
>
> Everything is good. Now if I compile :
>
> /*--- test.c ---*/
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> struct addrinfo *ai_out;
> struct passwd *pw;
> int error;
>
> pw = getpwnam("_bgpd");
>
> error = 0
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> chroot(pw->pw_dir);
>
> error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
>
> return 0;
> }
> /*--- test.c ---*/
>
> $ ./a.out
> getaddrinfo() succeed
> getaddrinfo() succeed
>
> # ./a.out
> getaddrinfo() succeed
> getaddrinfo() failed
>
>
>
> If this an expected behavior, what would be the preferred way to resolve
> a name from a chrooted process ? I am extending OpenBGPd and I need to
> resolve domain names and connect to a service (no BGP protocol). I am
> currently using the "session" process to handle the connection part but
> I am stuck on name resolution for now.
/etc/resolv.conf is read on the first attempt to resolve something,
no? And, of course, you have no /your/chroot/path/etc/resolv.conf.
--
WBR,
Vadim Zhukov
Re: firefox-26.0p1.tgz signature verification FAIL
On 2014-05-14, Marc Espie wrote: > There's no point in providing SHA256.sig for packages. We provide the SHA256 file to allow bulk integrity checking of the packages. There may be little point in signing it, but signing it also doesn't cost us anything, so why not? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: getaddrinfo(3) & chroot(2) with root
> After chroot, /etc/resolv.conf is no longer available. > Thank you very much Ted & Vadim. > Other daemons like ntpd have a helper process that runs outside chroot > and does all of the DNS resolution for them. > Ok, I'll look on this side. Thank you, Denis
Weird tmux pane separator chars in wsconsole
Hello, I'm trying to configure tmux on OBSD 5.5 in console (no X11). My laptop is a Thinkpad R61 equipped with an Intel GM965 video card, so I'm in KMS mode, if that matters. The problem is that when I split a windows in two or more panes, the separators are "" characters, both horizontally and vertically (instead of "|" and "-"). Strangely enough, if I enable UTF-8 (which is, to my best understanding, not supported in console), the separators change to "", so for sure there is an impact of the encoding... It's worth noting that in Xterm all works as expected. Any hints? Thanks in advance -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
building -stable fails on 5.5
I can't seem to get -stable to build. It fails at exactly this spot every
time. The kernel and xorg compiles to release just fine.
...
Creating Makefile in src/main
Creating Makefile in src/modules/standard
diff -u /usr/src/usr.sbin/httpd/src/include/ap_config_auto.h
/usr/src/usr.sbin/httpd/obj/src/include/ap_config_auto.h.new
--- /usr/src/usr.sbin/httpd/src/include/ap_config_auto.hTue Dec 9
12:33:30 2008
+++ /usr/src/usr.sbin/httpd/obj/src/include/ap_config_auto.h.newTue
May 13 22:57:59 2014
@@ -86,14 +86,4 @@
#define HAVE_SOCKADDR_LEN 1
#endif
-/* build flag: -DMOD_SSL=208116 */
-#ifndef MOD_SSL
-#define MOD_SSL 208116
-#endif
-
-/* build flag: -DEAPI */
-#ifndef EAPI
-#define EAPI 1
-#endif
-
#endif /* AP_CONFIG_AUTO_H */
*** Error 1 in usr.sbin/httpd (Makefile.bsd-wrapper:646
'/usr/src/usr.sbin/httpd/obj/config.status')
*** Error 1 in usr.sbin (:48 'all')
*** Error 1 in . (:48 'all')
*** Error 1 in /usr/src (Makefile:89 'build')
# cat /usr/src/CVS/Tag
TOPENBSD_5_5
OpenBSD 5.5 (GENERIC) #276: Wed Mar 5 09:57:06 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Sempron(tm) Processor 2800+ ("AuthenticAMD" 686-class, 256KB L2
cache) 1.61 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,SSE3,LAHF
real mem = 2129817600 (2031MB)
avail mem = 2082729984 (1986MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/14/05, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.3 @ 0xf0530 (54 entries)
bios0: vendor American Megatrends Inc. version "0204" date 10/14/2005
bios0: ASUSTeK Computer Inc. K8V-MX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC OEMB
acpi0: wakeup devices PCI0(S4) PS2K(S4) PS2M(S4) UAR2(S4) AC97(S4) USB1(S4)
USB2(S4) USB3(S4) USB4(S4) EHCI(S4) ILAN(S4) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: AMD erratum 89 present, BIOS upgrade may be required
cpu0: apic clock running at 200MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 3, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpicpu0 at acpi0
aibs0 at acpi0 RTMP RVLT RFAN
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0x8200 0xc8800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA K8M800 Host" rev 0x00
agp at pchb0 not configured
pchb1 at pci0 dev 0 function 1 "VIA K8M800 Host" rev 0x00
pchb2 at pci0 dev 0 function 2 "VIA K8M800 Host" rev 0x00
pchb3 at pci0 dev 0 function 3 "VIA K8M800 Host" rev 0x00
pchb4 at pci0 dev 0 function 4 "VIA K8M800 Host" rev 0x00
pchb5 at pci0 dev 0 function 7 "VIA K8M800 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA K8HTB AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "VIA S3 Unichrome PRO IGP" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 11 function 0 "Intel 82541GI" rev 0x05: apic 1 int 16,
address 00:1b:21:0b:d9:90
rl0 at pci0 dev 13 function 0 "Realtek 8139" rev 0x10: apic 1 int 18,
address 00:20:18:8a:46:e2
rlphy0 at rl0 phy 0: RTL internal PHY
pciide0 at pci0 dev 15 function 0 "VIA VT6420 SATA" rev 0x80: DMA
pciide0: using apic 1 int 20 for native-PCI interrupt
pciide1 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x06: ATA133,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide1 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 76318MB, 156299375 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide1: channel 1 disabled (no drives)
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x81: apic 1 int 21
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x81: apic 1 int 21
uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x81: apic 1 int 21
uhci3 at pci0 dev 16 function 3 "VIA VT83C572 USB" rev 0x81: apic 1 int 21
ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x86: apic 1 int 21
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "VIA EHCI root hub" rev 2.00/1.00 addr 1
viapm0 at pci0 dev 17 function 0 "VIA VT8237 ISA" rev 0x00: SMI
iic0 at viapm0
spdmem0 at iic0 addr 0x50: 1GB DDR SDRAM non-parity PC3200CL3.0
spdmem1 at iic0 addr 0x51: 1GB DDR SDRAM non-parity PC3200CL3.0
auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97" rev 0x60: apic 1 int 22
ac97: codec id 0x41445368 (Analog Devices AD1888)
ac97: codec features headphone, 20 bit DAC, No 3D Stereo
audio0 at auvia0
vr0 at pci0 dev 18 function 0 "VIA RhineII-2" rev 0x78: apic 1 int 23,
address 00:15:f2:4c:31:e6
rlphy1 at vr0 phy 1: RTL8201L 10/100 PHY, rev. 1
pchb6 at pci0 dev 24 function 0 "AMD AMD64 0Fh HyperTransport" rev 0x00
pchb7 at pci0 dev 24 function 1 "AMD AMD64 0Fh Address Map" rev 0x00
pchb8 at p
Re: getaddrinfo(3) & chroot(2) with root
Denis Fondras wrote:
> Hello all,
>
> I am burning my last neurons with a behavior I can't explain. I wonder
> why getaddrinfo() fails when called after chroot() with root user.
>
>
> I have this piece of code :
>
...
> error = getaddrinfo("rpki.liopen.eu", NULL, NULL, &ai_out);
> if (error)
> printf("getaddrinfo() failed\n");
> else printf("getaddrinfo() succeed\n");
...
Apart from the other suggestions you got, I'm wandering why don't you try to
get more information about the error using the gai_strerror(3) function ?
(like in the example of getaddrinfo(3))
Re: getaddrinfo(3) & chroot(2) with root
On Wed, May 14, 2014 at 07:41:47PM +0200, Denis Fondras wrote: > > After chroot, /etc/resolv.conf is no longer available. > > > > Thank you very much Ted & Vadim. > > > Other daemons like ntpd have a helper process that runs outside chroot > > and does all of the DNS resolution for them. > > > > Ok, I'll look on this side. > > Thank you, > Denis A quick way to solve this (but an administrative headache) is to create etc/resolv.conf in your chroot. -Otto
Re: Weird tmux pane separator chars in wsconsole
On Wed 14/05, Alessandro DE LAURENZIS wrote: > Hello, > > I'm trying to configure tmux on OBSD 5.5 in console (no X11). > My laptop is a Thinkpad R61 equipped with an Intel GM965 video card, so > I'm in KMS mode, if that matters. > > The problem is that when I split a windows in two or more panes, the > separators are "" characters, both horizontally and vertically > (instead of "|" and "-"). > > Strangely enough, if I enable UTF-8 (which is, to my best > understanding, not supported in console), the separators change to > "", so for sure there is an impact of the encoding... > > It's worth noting that in Xterm all works as expected. > After further investigation and searching, this seems to be related to some kind of mismatch between OBSD console and the terminfo database entry being used by tmux. Maybe the terminfo db indicates that ACS is available, but wsconsole is not actually respecting the specified control sequences? Un-setting the ACS features, tmux is forced to fall back to ASCII line drawing, and the problem disappears: ~/.tmux.conf set-option -g terminal-overrides ',*vt*:enacs@:smacs@:rmacs@:acsc@' In any case, UTF-8 encoding must be switched off. I'm not an expert, so I don't think I can do more than this... I really hope in your comments. Cheers -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: something fishy with portmapper on i386 snapshot?
On Tue, 13 May 2014, Sebastian Reitenbach wrote:
> I've installed a i386 soekris box (10.0.0.27, called wormhole) from
> current snapshot, and trying to netboot a vax and a sparc, but I guess,
> they don't get to the bootparamd.
Actually, there's a trick involved and they don't *directly* do so.
Instead, their request to portmap is a "call this proc in this other
service" request, for which portmap relays back the answer.
...
> With tcpdump I've seen, what I guess its getting rarp information
> correctly, then broadcasting to try to find the bootparamd, the
> portmapper on my box answers, and then its what I guess trying to
> contact the bootparamd, but this fails. As I guess, its trying to
> contact the bootparamd on UDP port 639, but there is nothing listen,
> bootparamd is listening on UDP 805. Does the portmapper give out the
> wrong port?
>
> root@wormhole:~# tcpdump -n -i vr0 -e -ttt -vvv -s 2000 -X host 10.0.0.30
> tcpdump: listening on vr0, link-type EN10MB
> May 13 09:01:54.903204 00:00:24:c9:d4:98 08:00:2b:2d:33:2c 8035 42: rarp
> reply 08:00:2b:2d:33:2c at 10.0.0.30
> : 0800 2b2d 332c 24c9 d498 8035 0001 ..+-3,..$5..
> 0010: 0800 0604 0004 24c9 d498 0a00 001b $...
> 0020: 0800 2b2d 332c 0a00 001e ..+-3,
>
> May 13 09:01:54.941453 08:00:2b:2d:33:2c ff:ff:ff:ff:ff:ff 0800 138:
> 10.0.0.30.986 > 255.255.255.255.111: [udp sum ok] udp 96 (ttl 4, id 0, len
> 124)
> : 0800 2b2d 332c 0800 4500 +-3,..E.
> 0010: 007c 0411 ac54 0a00 001e .|...T..
> 0020: 03da 006f 0068 e2d6 0027 .o.h.'..
> 0030: 0002 0001 86a0 0002
> 0040: 0005 0001 0014
> 0050:
> 0060: 0001 86ba 0001
> 0070: 0001 0014 0001 000a
> 0080: 001e ..
>
>
> the broadcast to the portmapper
That's the "call bootparam's 'whoami' call for me" request. The "0005" at
offset 040 is PMAPPROC_CALLIT, etc.
> May 13 09:01:54.949153 00:00:24:c9:d4:98 08:00:2b:2d:33:2c 0800 110:
> 10.0.0.27.111 > 10.0.0.30.986: [bad udp cksum 9f2d!] udp 68 (ttl 64, id
> 49240, len 96, bad cksum 0! differs by a5fc)
> : 0800 2b2d 332c 24c9 d498 0800 4500 ..+-3,..$.E.
> 0010: 0060 c058 4011 0a00 001b 0a00 .`.X..@.
> 0020: 001e 006f 03da 004c 1496 0027 ...o...L.'..
> 0030: 0001
> 0040: 0325 0024 0008 6461 .%...$da
> 0050: 6564 616c 7573 0001 edalus..
> 0060: 007f 0001 ..
>
> the answer
...from bootparamd, relayed by portmap. Note that it contains the
client_name ("daedalus") you would expect to get back from bootparamd.
That's confirmed by the vax boot saying:
> boot: client name: daedalus
One odd bit is that it looks like the router_address is "127.0.0.0", which
seems odd. But maybe I'm decoding the RPC by eyeball incorrectly.
More importantly, we can see the correct bootparam port number in
portmapper's reply: 0x0325 (at offset 0044) == 805. That value is
(supposed to be) remember by boot and used as the port to which to send
the direct bootparam "getfile" query.
> May 13 09:01:54.980649 08:00:2b:2d:33:2c 00:00:24:c9:d4:98 0800 122:
> 10.0.0.30.985 > 10.0.0.27.639: [udp sum ok] udp 80 (ttl 4, id 0, len
> 108)
Hmm, could you verify that the VAX boot block you're using was compiled
with a gcc that was built with miod@'s April 12th fix to
gnu/usr.bin/gcc/gcc/protector.c ?
Philip Guenther
ha firewall hardware suggestions
Hi OpenBSD hackers, At work we have a firewall on two Dell PowerEdge 2940 servers, with 10 NIC's in use, which I want to substiute in the near future. The second machine act as cold standby. I would like to use OpenBSD pf and carp/pfsync to make a ha firewall. I further want to use an embedded system to reduce heat and power consumption in our server room. What hardware would you suggest? Would a Soekris net6501-30 with two lan1841 be powerful enough to route and filter ip traffic for 50 clients in the LAN and 50 servers in the DMZ with a 300 Mbit uplink? Is there any other embedded system supported by OpenBSD with at least 9 gigabit ethernet network interfaces? Any octeon system available? Thanks in advance for any suggestion. best regards Waldemar
