Re: which monitoring do you use (on OpenBSD)
I like Zenoss, though the new interface is a little difficult to understand. Also, the OP wanted something that he can run on OpenBSD and Zenoss runs on Linux. I like splunk a lot as well. I use splunk to send events to Zenoss. -B On Sat, Aug 14, 2010 at 2:21 AM, Toni Mueller openbsd-m...@oeko.net wrote: On Fri, 13.08.2010 at 14:36:21 +0100, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: What do people think of monit. Ok, I'll chime in: What do people think of Zenoss and splunk? I'm so far leaning twoards trying Zenoss, but it surely has a high barrier-of-entry, and I'm only interested in splunk for comparison. Kind regards, --Toni++
Re: Use of -n flag with rdate on Sun V100 with latest snapshots give Bus error (core dumped) and do not work
On Sun, Aug 15, 2010 at 2:32 AM, Daniel Ouellet dan...@presscom.net wrote:
In trying the latest snapshots on sparc64 servers, so far 3 of them all give
me the same errors. I can't use the -n flag anymore with rdate as before.
It worked on 4.7 and before. Not sure of the exact date it stop working.
Any suggestions?
Probably an aligment problem.
Try this patch:
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.29
diff -u -r1.29 ntp.c
--- ntp.c 17 Sep 2006 17:03:56 - 1.29
+++ ntp.c 15 Aug 2010 07:12:11 -
@@ -305,7 +305,8 @@
int
read_packet(int fd, struct ntp_data *data, double *off, double *error)
{
- u_char receive[NTP_PACKET_MAX];
+ u_int64_t receivebuf[howmany(NTP_PACKET_MAX, sizeof(u_int64_t))];
+ u_char *receive = (u_char *)receivebuf;;
struct timeval tv;
double x, y;
int length, r;
--
Matthieu Herrb
Re: Web hosting, restrict user to access only his folder
Thank a lot for your reply. Now, it works, what i done : All users (firstorg,2ndcom,thirdnet are members of users) cd /var/www/domains chown -R firstorg www.first.org chown -R 2ndcom www.2nd.com chown -R third.net www.third.net chgrp -R users * chmod -R 745 * Now, user 2ndcom can only view, modify only his folder www.2nd.com ** And for MTA choice, i will try to install postfix ;-)
Re: which monitoring do you use (on OpenBSD)
On Tue, Aug 10, 2010 at 06:05:51PM -0400, Jason Dixon wrote: On Tue, Aug 10, 2010 at 01:11:41PM -0700, James Peltier wrote: Being as I have never used Reconnoiter or Circonus, would you care to elaborate as to where these products suck less then Nagios or other solutions? I am looking into replacing out very aged monitoring system now and Nagios is the one that seems to stand out the most, although Zabbix and Munin look good in their own rights. Theo Schlossnagle (our CEO and the architect of Reconnoiter) answers it pretty well in his talk from OSCON (requires flash, sorry). http://omniti.com/video/noit-oscon-demo In my words, Reconnoiter was designed to overcome a lot of the performance and design problems native in Nagios and Cacti. It does a lot of the things that either of those do, although it was designed foremost as a highly scalable metrics collection engine. Like Nagios, the types of checks it can perform is virtually limitless. Unlike Nagios, it is highly performant by design. Checks are deployed across scout agents in your network, giving you both perspective and non-persective collection points. The web UI in Reconnoiter is adequate. One of its really nice features is the cli console, allowing you to configure checks and metrics in an environment familiar to Cisco admins. Though from cli you can't reuse templates, which are very handy - thus for me checks are added in config file. Admittedly reloading of it is pretty painless. That said, the bread-and-butter in Reconnoiter is the sort of graphs which you can create and recreate with ease. Unlike trending tools like Cacti, you can easily correlate dissimilar metrics in a single graph, with just a few clicks. Stack sets, composite datapoints and RPN conversion of source and display values are just a few of the other features that are easy to implement within Reconnoiter. Well, for this it would be highly appreciated if you would expand on the templating system that there are seeds of present ;) Clicking through creating graphs for those 20 metrics each on 20 machines is a pain... Guidance is always appreciated. :) Reconnoiter is not for everyone. It's a very powerful system, but it's not intended to be a drop-in replacement for other ECA/Trending systems. It takes time and effort to get value out of it, but it offers some Capacity Planning and Root Cause Analysis capabilities that aren't available or usable in the alternatives. Agreed, it takes a while to figure out how to set it up, but the graphs are pretty impressive. And I already at least once post-factum created a set of graphs showing correlation between various metrics on multiple machines, showing where possibly the problem came from. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/ -- viq
Re: which monitoring do you use (on OpenBSD)
On Sun, Aug 15, 2010 at 12:01:27AM -0400, Jason Dixon wrote: On Wed, Aug 11, 2010 at 10:07:53PM +0200, Jiri B. wrote: On Tue, 10 Aug 2010 18:05:51 -0400 Jason Dixon ja...@dixongroup.net wrote: http://omniti.com/video/noit-oscon-demo Sorry no flash :) Some screenshots should be sufficient for this products, interesting is there are no screenshots except that architecture picture. Here's a quick one I just grabbed. We don't actively use Reconnoiter these days as much as we do Circonus. http://www.flickr.com/photos/78527...@n00/4892326857/ Does it have some event console? So an operator can watch it 24x7 and see if something goes wrong and do a repair action? It has support for alerting in stratcon (iirc), but no fault detection functionality is exposed in Reconnoiter's current web UI. Well, yes and no. There is the whole esper stuff that indeed is in there, but is described even by the creator as a bit of black magic ;) Another thing is that you can use for example curl to periodically query values of the metrics gathered, and for example feed them to nagios, and have it react to them changing. In short - it is an infrastructure to gather metrics from a lot of places, in various ways. And a web interface that allows you to make pretty graphs of them. For anything more, there are proper pieces in it, but you need to figure out yourself how to operate them and write something that will plug into them. It's nice it can act as snmp trap daemon... A lot of SAN devices have SNMP and Vmware ESXes can make good monitoring via SNMP as well. In our enterprise environment we have huge operators centers which watch 24x7 Tivoli Enteprise Console (yeah, ld shite), but what I saw is that one can right client on an event and run an action directly from event console (OK, it is not used at all but nice feature and you exclude possibility to fuck up something just with a similar but bad commmand). P.S. Sorry for the slow response, been enjoying my vacation. :) -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/ -- viq
Re: Use of -n flag with rdate on Sun V100 with latest snapshots give Bus error (core dumped) and do not work
On Sun, Aug 15, 2010 at 09:16:32AM +0200, Matthieu Herrb wrote:
On Sun, Aug 15, 2010 at 2:32 AM, Daniel Ouellet dan...@presscom.net wrote:
In trying the latest snapshots on sparc64 servers, so far 3 of them all give
me the same errors. I can't use the -n flag anymore with rdate as before.
It worked on 4.7 and before. Not sure of the exact date it stop working.
Any suggestions?
Probably an aligment problem.
Try this patch:
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.29
diff -u -r1.29 ntp.c
--- ntp.c 17 Sep 2006 17:03:56 - 1.29
+++ ntp.c 15 Aug 2010 07:12:11 -
@@ -305,7 +305,8 @@
int
read_packet(int fd, struct ntp_data *data, double *off, double *error)
{
- u_char receive[NTP_PACKET_MAX];
+ u_int64_t receivebuf[howmany(NTP_PACKET_MAX, sizeof(u_int64_t))];
+ u_char *receive = (u_char *)receivebuf;;
struct timeval tv;
double x, y;
int length, r;
--
Matthieu Herrb
There may be a similar potential issue in write_packet. Here I use
bcopy() rather than aligning the buffer on the stack. Not sure what
the preferred idiom is. This way it will continue to work if
recvck/xmitck ever become u_int128_t. :-).
Ken
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.29
diff -u -p -r1.29 ntp.c
--- ntp.c 17 Sep 2006 17:03:56 - 1.29
+++ ntp.c 15 Aug 2010 11:01:55 -
@@ -280,9 +280,11 @@ write_packet(int fd, struct ntp_data *da
* No endian concerns here. Since we're running as a strict
* unicast client, we don't have to worry about anyone else finding
* the transmit field intelligible.
+*
+* NOTE: packet is not necessarily aligned, so a (u_int64_t *) would
+* be bad on aligned architectures!
*/
-
- *(u_int64_t *)(packet + NTP_TRANSMIT) = data-xmitck;
+ bcopy(data-xmitck, (packet + NTP_TRANSMIT), sizeof(data-xmitck));
data-originate = current_time(JAN_1970);
@@ -423,8 +425,13 @@ unpack_ntp(struct ntp_data *data, u_char
data-transmit = d / NTP_SCALE;
- /* See write_packet for why this isn't an endian problem. */
- data-recvck = *(u_int64_t *)(packet + NTP_ORIGINATE);
+ /*
+* See write_packet for why this isn't an endian problem.
+*
+* NOTE: packet is not necessarily aligned, so a (u_int64_t *) would
+* be bad on aligned architectures!
+*/
+ bcopy((packet + NTP_ORIGINATE), data-recvck, sizeof(data-recvck));
}
/*
Re: Use of -n flag with rdate on Sun V100 with latest snapshots give Bus error (core dumped) and do not work
I just tested the first one first from Matthieu.
That worked.
Also, just fyi. Shouldn't the line have only one ;;
+ u_char *receive = (u_char *)receivebuf;;
Not a big deal for sure. (;
I will test Kenneth one in a few minutes and report back too.
On 8/15/10 7:08 AM, Kenneth R Westerback wrote:
On Sun, Aug 15, 2010 at 09:16:32AM +0200, Matthieu Herrb wrote:
On Sun, Aug 15, 2010 at 2:32 AM, Daniel Ouelletdan...@presscom.net wrote:
In trying the latest snapshots on sparc64 servers, so far 3 of them all give
me the same errors. I can't use the -n flag anymore with rdate as before.
It worked on 4.7 and before. Not sure of the exact date it stop working.
Any suggestions?
Probably an aligment problem.
Try this patch:
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.29
diff -u -r1.29 ntp.c
--- ntp.c 17 Sep 2006 17:03:56 - 1.29
+++ ntp.c 15 Aug 2010 07:12:11 -
@@ -305,7 +305,8 @@
int
read_packet(int fd, struct ntp_data *data, double *off, double *error)
{
- u_char receive[NTP_PACKET_MAX];
+ u_int64_t receivebuf[howmany(NTP_PACKET_MAX, sizeof(u_int64_t))];
+ u_char *receive = (u_char *)receivebuf;;
struct timeval tv;
double x, y;
int length, r;
--
Matthieu Herrb
There may be a similar potential issue in write_packet. Here I use
bcopy() rather than aligning the buffer on the stack. Not sure what
the preferred idiom is. This way it will continue to work if
recvck/xmitck ever become u_int128_t. :-).
Ken
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.29
diff -u -p -r1.29 ntp.c
--- ntp.c 17 Sep 2006 17:03:56 - 1.29
+++ ntp.c 15 Aug 2010 11:01:55 -
@@ -280,9 +280,11 @@ write_packet(int fd, struct ntp_data *da
* No endian concerns here. Since we're running as a strict
* unicast client, we don't have to worry about anyone else finding
* the transmit field intelligible.
+*
+* NOTE: packet is not necessarily aligned, so a (u_int64_t *) would
+* be bad on aligned architectures!
*/
-
- *(u_int64_t *)(packet + NTP_TRANSMIT) = data-xmitck;
+ bcopy(data-xmitck, (packet + NTP_TRANSMIT), sizeof(data-xmitck));
data-originate = current_time(JAN_1970);
@@ -423,8 +425,13 @@ unpack_ntp(struct ntp_data *data, u_char
data-transmit = d / NTP_SCALE;
- /* See write_packet for why this isn't an endian problem. */
- data-recvck = *(u_int64_t *)(packet + NTP_ORIGINATE);
+ /*
+* See write_packet for why this isn't an endian problem.
+*
+* NOTE: packet is not necessarily aligned, so a (u_int64_t *) would
+* be bad on aligned architectures!
+*/
+ bcopy((packet + NTP_ORIGINATE),data-recvck, sizeof(data-recvck));
}
/*
Re: Use of -n flag with rdate on Sun V100 with latest snapshots give Bus error (core dumped) and do not work
On 8/15/10 7:08 AM, Kenneth R Westerback wrote:
On Sun, Aug 15, 2010 at 09:16:32AM +0200, Matthieu Herrb wrote:
On Sun, Aug 15, 2010 at 2:32 AM, Daniel Ouelletdan...@presscom.net wrote:
In trying the latest snapshots on sparc64 servers, so far 3 of them all give
me the same errors. I can't use the -n flag anymore with rdate as before.
It worked on 4.7 and before. Not sure of the exact date it stop working.
Any suggestions?
Probably an aligment problem.
Try this patch:
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.29
diff -u -r1.29 ntp.c
--- ntp.c 17 Sep 2006 17:03:56 - 1.29
+++ ntp.c 15 Aug 2010 07:12:11 -
@@ -305,7 +305,8 @@
int
read_packet(int fd, struct ntp_data *data, double *off, double *error)
{
- u_char receive[NTP_PACKET_MAX];
+ u_int64_t receivebuf[howmany(NTP_PACKET_MAX, sizeof(u_int64_t))];
+ u_char *receive = (u_char *)receivebuf;;
struct timeval tv;
double x, y;
int length, r;
--
Matthieu Herrb
There may be a similar potential issue in write_packet. Here I use
bcopy() rather than aligning the buffer on the stack. Not sure what
the preferred idiom is. This way it will continue to work if
recvck/xmitck ever become u_int128_t. :-).
Ken
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/rdate/ntp.c,v
retrieving revision 1.29
diff -u -p -r1.29 ntp.c
--- ntp.c 17 Sep 2006 17:03:56 - 1.29
+++ ntp.c 15 Aug 2010 11:01:55 -
@@ -280,9 +280,11 @@ write_packet(int fd, struct ntp_data *da
* No endian concerns here. Since we're running as a strict
* unicast client, we don't have to worry about anyone else finding
* the transmit field intelligible.
+*
+* NOTE: packet is not necessarily aligned, so a (u_int64_t *) would
+* be bad on aligned architectures!
*/
-
- *(u_int64_t *)(packet + NTP_TRANSMIT) = data-xmitck;
+ bcopy(data-xmitck, (packet + NTP_TRANSMIT), sizeof(data-xmitck));
data-originate = current_time(JAN_1970);
@@ -423,8 +425,13 @@ unpack_ntp(struct ntp_data *data, u_char
data-transmit = d / NTP_SCALE;
- /* See write_packet for why this isn't an endian problem. */
- data-recvck = *(u_int64_t *)(packet + NTP_ORIGINATE);
+ /*
+* See write_packet for why this isn't an endian problem.
+*
+* NOTE: packet is not necessarily aligned, so a (u_int64_t *) would
+* be bad on aligned architectures!
+*/
+ bcopy((packet + NTP_ORIGINATE),data-recvck, sizeof(data-recvck));
}
/*
Redoing it clean from the original and use only this one works too.
Both are good and solved the problem. Not sure witch one should be use
in the end. You guys know better. I suppose the second one, but what do
I know really. (; May even be something else coming.
Let me know should you need more tests and thanks again!
Best,
Daniel
Re: New port: sysutils/dtpstree
On Sat, Aug 14, 2010 at 10:38, Douglas Thrift douglas...@gmail.com wrote: On 7/25/2010 11:03 PM, Douglas Thrift wrote: Hello, I would appreciate any comments on my port. Thanks! works on aug 11 amd64 snapshot /Henrik
Re: anyone tried the freebsd version of teamspeak3 with the freebsd emulation?
Siju George wrote: On Sat, Aug 14, 2010 at 6:08 PM, Stuart Henderson s...@spacehopper.org wrote: On 2010-08-14, Sevan / Venture37 ventur...@gmail.com wrote: On 14 August 2010 10:46, Stuart Henderson s...@spacehopper.org wrote: no, but in general you want to use Linux emulation not FreeBSD emulation. also, if it's threaded software, use GENERIC not GENERIC.MP. Hi Stuart, I'm just curious is that because of limitations in our freebsd compatibility layer? It's even less maintained than the linux one (and there's very little point in doing so; most things you might run as a binary are going to be available for Linux in either the same or a newer version as FreeBSD). You don't get sound in linux emulation right? I could never make sound work I'm running Ventrilo with linux emulation; does that count?
Re: OpenBSD on RouterBoard 450G
On Sun, 8 Aug 2010, Jozsi Vadkan wrote: Did anyone manage to install, and use/test OpenBSD on the RouterBoard 450G? Or does anyone has a howto for it, how to do it? IIRC back in March, Mark Kettennis added support for the RouterBoard 600A. However, that's a different processor. The 1000 and 1100 also use PPC. The 1000 is a bit closer to the 450 though with 4 ports and two CF slots. /Lars
Seminario sobre Administración de Recursos Humanos, México D.F. Agosto 20
[IMAGE] B!Promociones Especiales para Grupos! Mayores informes responda este correo electrC3nico con los siguientes datos. Empresa: Nombre: TelC)fono: Email: NC:mero de Interesados: Y en breve le haremos llegar la informaciC3n completa del evento. O bien comunCquense a nuestros telC)fonos un ejecutivo con gusto le atenderC! Tels. (33) 8851-2365, (33)8851-2741. Copyright (C) 2010, PMS CapacitaciC3n Efectiva de MC)xico S.C. Derechos Reservados. PMS de MC)xico, El logo de PMS de MC)xico son marcas registradas. ADVERTENCIA PMS de MC)xico no cuenta con alianzas estratC)gicas de ningC:n tipo dentro de la Republica Mexicana. NO SE DEJE ENGACAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imC!genes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de MC)xico o bien un usuario le refiriC3 para recibir este boletCn. Como usuario de Pms de MC)xico, en este acto autoriza de manera expresa que Pms de MC)xico le puede contactar vCa correo electrC3nico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJARECURSOSHUMANOS Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJARECURSOSHUMANOS Tenga en cuenta que la gestiC3n de nuestras bases de datos es de suma importancia y no es intenciC3n de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/jpeg which had a name of 20 de agosto recursos humanos.jpg]
Re: Same shit all over again
This email comes from kd85.com. contact-hdl: CCOM-138654 person: Wim Vandeputte organization: KD85.com bvba email:w...@kd85.com address: Kasteeldreef 85 city: Lovendegem postal-code: 9920 country: BE phone:+32.478217355 On 08/13/10 13:46, disgrun tled-developers wrote: Just to keep the mortals in the loop, This date to day, on Tuesday the 13th of August 2002, Theo had another fit and kicked out all the OpenBSD developers for a couple of days or so: Subject: Re: dealing with security issues when Theo is away Date: Tue, 13 Aug 2002 10:25:08 -0600 From: Theo de Raadt dera...@cvs.openbsd.org None of this that you posted changes a single thing. I DID say who was responsible. Those people were not contacted. It seems you still don't understand the level of not caring that happened. I am taking a holiday next week. For that time, I think cvs will be turned off. Good god, reading even further, you are so fucking out of touch. There are only 3 machines on at my house at the moment, and you start talking about OTHER machines? NOONE PHONED ME. And: Subject: And Date: Wed, 14 Aug 2002 17:35:30 -0600 From: Theo de Raadt dera...@cvs.openbsd.org If I don't get answers from the evasive developers soon, I am going to take this to misc, and I will be very open with naming names. This is now days of people trying to hide from what happened. -- snip snip So Theo shut down all machines in his basement and none of the developers had any access to the work they doing. I'd like to remind people that at this point we lost valuable developers like Niels Provos which turns out the be one of the few who fully understood crypto and the security improvements like separation of privileges. Not to forget Hugh, Aaron and a few others Others had their account re-enabled after groveling. And all that over a misunderstanding that is to blame to the fact that Theo had no written procedures on how to deal with 'issues'. When Theo is away, you just 'wing it'. Today, we see the same shit all over again... Theo just announced the following: - snip snip To: hack...@cvs.openbsd.org Subject: Tree locked Date: Fri, 13 Aug 2010 10:03:05 -0600 From: Theo de Raadt dera...@cvs.openbsd.org I am locking all the trees until the development community decides how future releases will be done. Yes, we all have to do our part. We write code, and some people go further by building, and some people go even further by building during the release cycle. But everyone also has to test, or we will ship crap. Yet on random releases this process totally falls over, and we end up shipping crap. Three architectures did not have one of their boot methods checked -- yes, they are listed in the TESTS file! -- and the bugs were found very very late in the process. Basically 1 week after the TEST file went up. pkg_add turns out to have a major bug which would have been spotted if just a few other people had tested another line item in the TESTS file. That is ridiculous. I cannot accept all this pressure being on me; I want recognition that all the people who thus far have accused me for not being clear are wrong. we have developers in the group who cannot by themselves recognize -- even ANTICIPATE -- that we are going into the same 6-month release cycle, EVERY feb/march, and EVERY august/sept, and then participate to identify the 10 last stupid bugs that we should fix. Is there that little desire to ship a good release? It will not be fixed by sending more mails out. I did send out mails and they were ignored. Communication coming from me is not the problem; it is clear that developers are NOT LISTENING. The problem is not new developers either. Anyone accusing them has got it all wrong. New developers are supposed to learn the ropes from old developers, and it is the old developers who are not doing their part. Yes, that means you. 31 people tested, meaning 140 people did not. Any suggestions for people who have idled out and don't want to be involved any more? When we ship a crap release, it is not my fault. It is YOUR fault. So tell me how we are going to fix this. Don't reply just to me. As I said, I will not accept responsibility for what went wrong here. And if anyone wants their account disabled, please accuse me just once more. - snip snip And he picks on a few individuals: - snip snip To: hack...@cvs.openbsd.org Subject: Testing Date: Fri, 13 Aug 2010 09:39:12 -0600 From: Theo de Raadt dera...@cvs.openbsd.org I would like to see some tests for the upcoming release from Henning. I hope this communication is clear enough. - snip snip To: henn...@cvs.openbsd.org cc: hack...@cvs.openbsd.org Subject: Apology Date: Fri, 13 Aug 2010 09:44:45 -0600 From: Theo de Raadt dera...@cvs.openbsd.org I
Re: Same shit all over again
On 08/15/10 22:22, David Hill wrote: This email comes from kd85.com. contact-hdl: CCOM-138654 person: Wim Vandeputte organization: KD85.com bvba email:w...@kd85.com address: Kasteeldreef 85 city: Lovendegem postal-code: 9920 country: BE phone:+32.478217355 And for those who wish to know how I came up with this: here is an email response from the culprit: email Nope, nothing to do with that... we all still have our commit bit and in two weeks we'll be committing to the tree again... just like you... unless of course you did not do your testing home work On Sun, Aug 15, 2010 at 7:25 PM, David Hill dh...@openbsd.org wrote: So, do you start this troll thread too? http://tinyurl.com/2uhlqpy (trollaxer) /email -- SNIP SNIP SNIP I CAN SNIP TOO -- Well, tinyurl redirects to my box which redirects to trollaxer. Here is the culprit log for falling for such a silly trick. 83.101.24.229 - - [15/Aug/2010:19:13:12 -0400] GET /why.html HTTP/1.1 200 136 - Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.9.0.11) Gecko/2009070118 Firefox/3.0.11 # host kd85.com kd85.com has address 83.101.24.229 # cat why.html html head meta http-equiv=refresh content=0;url=http://www.trollaxor.com/2010/06/why-i-left-openbsd.html; / /head /html On 08/13/10 13:46, disgrun tled-developers wrote: Just to keep the mortals in the loop, This date to day, on Tuesday the 13th of August 2002, Theo had another fit and kicked out all the OpenBSD developers for a couple of days or so: Subject: Re: dealing with security issues when Theo is away Date: Tue, 13 Aug 2002 10:25:08 -0600 From: Theo de Raadt dera...@cvs.openbsd.org None of this that you posted changes a single thing. I DID say who was responsible. Those people were not contacted. It seems you still don't understand the level of not caring that happened. I am taking a holiday next week. For that time, I think cvs will be turned off. Good god, reading even further, you are so fucking out of touch. There are only 3 machines on at my house at the moment, and you start talking about OTHER machines? NOONE PHONED ME. And: Subject: And Date: Wed, 14 Aug 2002 17:35:30 -0600 From: Theo de Raadt dera...@cvs.openbsd.org If I don't get answers from the evasive developers soon, I am going to take this to misc, and I will be very open with naming names. This is now days of people trying to hide from what happened. -- snip snip So Theo shut down all machines in his basement and none of the developers had any access to the work they doing. I'd like to remind people that at this point we lost valuable developers like Niels Provos which turns out the be one of the few who fully understood crypto and the security improvements like separation of privileges. Not to forget Hugh, Aaron and a few others Others had their account re-enabled after groveling. And all that over a misunderstanding that is to blame to the fact that Theo had no written procedures on how to deal with 'issues'. When Theo is away, you just 'wing it'. Today, we see the same shit all over again... Theo just announced the following: - snip snip To: hack...@cvs.openbsd.org Subject: Tree locked Date: Fri, 13 Aug 2010 10:03:05 -0600 From: Theo de Raadt dera...@cvs.openbsd.org I am locking all the trees until the development community decides how future releases will be done. Yes, we all have to do our part. We write code, and some people go further by building, and some people go even further by building during the release cycle. But everyone also has to test, or we will ship crap. Yet on random releases this process totally falls over, and we end up shipping crap. Three architectures did not have one of their boot methods checked -- yes, they are listed in the TESTS file! -- and the bugs were found very very late in the process. Basically 1 week after the TEST file went up. pkg_add turns out to have a major bug which would have been spotted if just a few other people had tested another line item in the TESTS file. That is ridiculous. I cannot accept all this pressure being on me; I want recognition that all the people who thus far have accused me for not being clear are wrong. we have developers in the group who cannot by themselves recognize -- even ANTICIPATE -- that we are going into the same 6-month release cycle, EVERY feb/march, and EVERY august/sept, and then participate to identify the 10 last stupid bugs that we should fix. Is there that little desire to ship a good release? It will not be fixed by sending more mails out. I did send out mails and they were ignored. Communication coming from me is not the problem; it is clear that developers are NOT LISTENING. The problem is not new developers either. Anyone accusing them has got it all wrong. New developers are supposed to learn the ropes from old developers, and it
ISC DHCP 4.2
I've done some digging online, but can't seem to find any pointers as to what is going on... I am running OpenBSD 4.7, and just installed the ISC DHCP 4.2 tarball. (the isc-dhcp in ports is only version 3) I have two network segments on my internal LAN. When running the ISC 4.2 dhcpd (using the old config file) in the foreground/debugging (-f or -f -d), clients on both my wired lan (segment 1) and wireless lan (segment 2) can obtain IP addresses just fine. When running the dhcpd server is daemon mode, only the wired lan clients can obtain IP addresses. FYI, the wired lan segment has its IP address range listed first in the dhcpd.conf file. I've tried disabling pf as well, but that didn't make any difference. Any suggestions on to what I can do to start digging into what is going on and how to fix it? Thanks, Michael
Re: ISC DHCP 4.2
On Sun, Aug 15, 2010 at 08:52:51PM -0700, Michael McCool wrote: When running the ISC 4.2 dhcpd (using the old config file) in the foreground/debugging (-f or -f -d), clients on both my wired lan (segment 1) and wireless lan (segment 2) can obtain IP addresses just fine. When running the dhcpd server is daemon mode, only the wired lan clients can obtain IP addresses. Any suggestions on to what I can do to start digging into what is going on and how to fix it? Just a quick guess from my not so recent experiece: Did you specify all the relevant interfaces in /etc/dhcpd.interfaces? -- Olivier Mehani sht...@ssji.net PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 [demime 1.01d removed an attachment of type application/pgp-signature]
