Re: NSA spy catalog (was: Re: apologies for the noise (interesting article)!)
Erling Westenvik [erling.westen...@gmail.com] wrote: > > The unit costs are pretty stiff for most of the gadgets but some of > them appear to be free. Anyway: When can we expect OpenBSD support for > these devices? > > http://www.spiegel.de/static/happ/netzwelt/2014/na/v1/pub/img/Mobilfunk/S3224_GENISIS.jpg $15K? They could save a lot of money using GNU SDR and some inexpensive hardware attachment. Damn liberals wasting all our hard-earned tax payer money!
Re: Request for Funding our Electricity
On Wed, Jan 15, 2014 at 12:40 AM, Donald Allen wrote: > On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck wrote: >>Just to bring this issue back to the forefront. >> >> In light of shrinking funding, we do need to look for a source to >> cover project expenses. If need be the OpenBSD Foundation can be >> involved in receiving donations to cover project electrical costs. >> >> But the fact is right now, OpenBSD will shut down if we do not have >> the funding to keep the lights on. >> >> If you or a company you know are able to assist us, it would be >> greatly appreciated, but right now we are looking at a significant >> funding shortfall for the upcoming year - Meaning the project won't be >> able to cover 20 thousand dollars in electrical expenses before being >> able to use money for other things. That sort of situation is not >> sustainable. > > There's an equation that has to be satisfied here. It has a demand > side and a supply side. You demand a certain amount of electricity and > someone has to supply the money to pay for it. I'm going to be blunt > here, in an effort to be helpful (it's also not foreign to the OpenBSD > style). I get the impression that the demand for electricity is viewed > as a given: you use what you use and people need to step up and > provide the money to pay for it. If I'm wrong, please say so. But if > I'm right, the demand can be adjusted. Sometimes you need to eat > cornflakes instead of caviar. For example, I've never understood why > this project supports the old architectures it does, considering the > associated costs. The recent discussion of a need for a replacement > Vax for package-building illustrates that. > > Perhaps this is an opportunity to reassess the scope of the project > and trim some things that can no longer be justified on a cost-benefit > basis. > > If the choice is between shutting the project down and reducing its > scope to something sustainable, it's a no-brainer. This project has > made really significant contributions, both in the obvious area, > security, but also to the art of managing and building complex > software that is reliable. To have it go away rather than trim its > sails in way that acknowledges reality would really be a shame. > > /Don Allen > I'm not involved deeply in OpenBSD, but you'd be surprised at the number of software that incorporates OpenBSD improvements that you and I use. If you run nsd or unbound: (from nsd changelog) Bugfixes: Fix for accept spinning reported by OpenBSD. OpenBSD security improvements are often submitted to other projects so that everybody can benefit: Fix bug where clear_remove() and clear_inodedeps() would not iterate over the entire pagedep and inodedep hash tables due to an off-by-one mistake in loops. Spotted by and diff from Pedro Martelletto. Sent upstream to Kirk and also fixed in FreeBSD. ok otto@ millert@ These are just 2 examples that I picked, but there are many more. OpenSSH wouldn't be reliable if it wasn't tested on HPPA and sparc64: (I'm pretty sure I saw a bunch of commits wrt to alignment issues that were discovered on HPPA or sparc64 for OpenSSH). If we "re-view the project", we end up with OpenBSD not being able to make continuous improvements to the whole world as well as it is doing right now. So let's do our best to allow the project to grow :-) ! >> >> >> >> >> On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt >> wrote: >>> I am resending this request for funding our electricity bills because >>> it is not yet resolved. >>> >>> We really need even more funding beyond that, because otherwise all of >>> this is simply unsustainable. This request is the smallest we can >>> make. >>> >>> --- >>> >>> Hi everyone. >>> >>> The OpenBSD project uses a lot of electricity for running the >>> development and build machines. A number of logistical reasons >>> prevents us from moving the machines to another location which might >>> offer space/power for free, so let's not allow the conversation to go >>> that way. >>> >>> We are looking for a Canadian company who will take on our electrical >>> expenses -- on their books, rather than on our books. We would be >>> happiest to find someone who will do this on an annual recurring >>> basis. >>> >>> That way the various OpenBSD efforts can be supported, yet written off >>> as an off-site operations cost by such a company. If we reduce this >>> cost, it will leave more money for other parts of the project. >>> >>> We think that a Canadian company is the best choice for accounting >>> reasons. If a company in some other jurisdiction feels they can also >>> do this successfully, we'd be very happy to hear from them as well. >>> >>> I am not going to disclose the actual numbers here. Please contact me >>> for details if serious. >>> >>> Thanks. >> > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: PPPoE "ip unnumbered"
On 2014-01-14, Martijn Rijkeboer wrote: > Hi, > > Is it possible to create an IP unnumbered setup with PPPoE on OpenBSD? > > Kind regards, > > > Martijn Rijkeboer > > Untested but I think you should be able to put an address from your lan interface on the pppoe interface which might do what you want.. Worth a try anyway.
Re: Request for Funding our Electricity
Perhaps it's time to slightly increase the cost of CD purchases. I know it's not a favorite thing to do, but necessary for sustainability. On 01/14/2014 07:30 PM, Jason Koch wrote: No need to respond to this: just ideas if they're not already covered. I've just made my donation. For what it's worth - you can see the numbers on wikimedia's donations, from 2009. I wouldn't discount the $10 user base. http://en.m.wikipedia.org/wiki/User:Staeiou/Protocol [see the graphs on fundraising below]. Other idea if not already taken care of - You could also get non-coding contributors to handle the CD & stickers etc, if you don't already have that happening. Then the fundraising arm wouldn't take away from coding time. Thanks Jason On Wed, Jan 15, 2014 at 9:24 AM, Theo de Raadt wrote: Anyone want to suggest we hold a bake sale? I will take this opportunity to suggest a probably bad idea but one that crossed my mind nonetheless. I have not actively kept up with this list so forgive me if this can't be done, or isn't in line with the community's values, but what about doing a Kickstarter campaign for each OpenBSD release? Varying levels of support could get the different levels of swag that are already distributed: CD/DVD distributions, t-shirts, stickers, etc... The problem with this model is that once again - we are the ones who need to supply more; - we need to promising the goods; - we are the ones who need to invest; - we are supposed to do the extra work; - we are supposed to take time away from coding. Don't we do enough? Regarding the swag. The entire OpenBSD project now probably gets 1/4 of revenue out of CD, tshirt sales, but in this model we'd have to give much of that out to people who contribute, and it will probably be less. Remember to add shipping, now paid on this end, instead of by the buyer. One could also just contribute $10-$20 to be a supporter, and receive nothing material. $20? To break even with the above issues, call it $100 minimum. Does it still work? Is there evidence? And once this turn process on, if it doesn't work, are we even more dead in the water? Nodejitsu recently raised $256k with their Scalenpm campaign. I would imagine there are enough people out there who care about OpenBSD too whereby a significant amount of money could be raised. Would that work every year? I doubt mindshare of this sort works repeatedly.
Re: Request for Funding our Electricity
On Tue, Jan 14, 2014 at 04:56:14PM -0600, Kent R. Spillner wrote: > Anyways, talk is cheap so I'm going to go make a donation now. If everyone > reading this did the same this thread could die, and OpenBSD wouldn't. +1 $10 monthly recurring donation Predrag
Re: Request for Funding our Electricity
Nicolai, and others, I'd like to take the opportunity to thank all of those stepping up to the call for contributions. Every little bit helps. For those who ask, the OpenBSD Foundation is the best path for contributions. I hope some larger contributors will step up, to take a more long term view (like Google does). Rather than the "little people" funding our efforts. Many of the things we do in OpenBSD are often incorporated into products made by multi-million dollar companies. This is not a BSD vs GPL issue, it is about a plain lack of goodwill, something you cannot mandate via a license. A lack of goodwill is effectively badwill. There is a good list in the last paragraph of the OpenSSH web site. Maybe the community's activism can make inroads there which we have not been able to.
Re: Bake Sale
>> --- Theo de Raadt wrote: >> Anyone want to suggest we hold a bake sale? > > I understand there is a market for brownies in Colorado and Washington state. > > Ken Hendrickson > > Not if you are a Fed!! Jay
Re: Request for Funding our Electricity
On Tue, Jan 14, 2014 at 04:56:14PM -0600, Kent R. Spillner wrote: > Anyways, talk is cheap so I'm going to go make a donation now. If everyone > reading this did the same this thread could die, and OpenBSD wouldn't. I just did the same, $100 via the OpenBSD Foundation. Feels good. I'm super excited about the 5.5 release, which should be the most amazing in years. Options to pay with Paypal, credit card, check... http://www.openbsd.org/donations.html Who else has donated today? Nicolai
Re: Request for Funding our Electricity
No need to respond to this: just ideas if they're not already covered. I've just made my donation. For what it's worth - you can see the numbers on wikimedia's donations, from 2009. I wouldn't discount the $10 user base. http://en.m.wikipedia.org/wiki/User:Staeiou/Protocol [see the graphs on fundraising below]. Other idea if not already taken care of - You could also get non-coding contributors to handle the CD & stickers etc, if you don't already have that happening. Then the fundraising arm wouldn't take away from coding time. Thanks Jason On Wed, Jan 15, 2014 at 9:24 AM, Theo de Raadt wrote: > > > Anyone want to suggest we hold a bake sale? > > > > I will take this opportunity to suggest a probably bad idea but one > > that crossed my mind nonetheless. > > > > I have not actively kept up with this list so forgive me if this can't > > be done, or isn't in line with the community's values, but what about > > doing a Kickstarter campaign for each OpenBSD release? Varying levels > > of support could get the different levels of swag that are already > > distributed: CD/DVD distributions, t-shirts, stickers, etc... > > The problem with this model is that once again > - we are the ones who need to supply more; > - we need to promising the goods; > - we are the ones who need to invest; > - we are supposed to do the extra work; > - we are supposed to take time away from coding. > > Don't we do enough? > > Regarding the swag. The entire OpenBSD project now probably gets 1/4 > of revenue out of CD, tshirt sales, but in this model we'd have to > give much of that out to people who contribute, and it will probably > be less. > > Remember to add shipping, now paid on this end, instead of by the buyer. > > > One could also just contribute $10-$20 to be a supporter, and receive > > nothing material. > > $20? To break even with the above issues, call it $100 minimum. Does > it still work? Is there evidence? > > And once this turn process on, if it doesn't work, are we even more dead > in the water? > > > Nodejitsu recently raised $256k with their Scalenpm campaign. I would > > imagine there are enough people out there who care about OpenBSD too > > whereby a significant amount of money could be raised. > > Would that work every year? > > I doubt mindshare of this sort works repeatedly.
Re: Request for Funding our Electricity
>previously on this list Theo contributed: > >> The OpenBSD project uses a lot of electricity for running the >> development and build machines. A number of logistical reasons >> prevents us from moving the machines to another location which might >> offer space/power for free, so let's not allow the conversation to go >> that way. > >Especially if you have some land in Canada and manage to raise a >significant bit extra, a Peltier energy harvesting system due to >the difference in surface and sub-surface land temperature might be >worth looking at to help balance the books longer term. > >The Aston Martin plant runs off one entirely but cost a fortune to >drill a deep bore hole to get a large temperature difference, but then >their building is huge and produces cars with enough power to run a >town. > >Alternatively a small scale system building it into a wall to get the >difference between the cold Canadian winter outside and warm inside >might work well. That's a great idea. I'm going drag a subgroup of the developers away from software development and we'll start working on that instead. Right away. To fund the drilling, we'll hold a bake sale.
Re: PPPoE "ip unnumbered"
Em 14-01-2014 19:24, Martijn Rijkeboer escreveu: > Hi, > > Is it possible to create an IP unnumbered setup with PPPoE on OpenBSD? > > Kind regards, > > > Martijn Rijkeboer > And what the heck you mean by "unnumbered"? If it is wildcard address, and by it, that the pppoe access concentrator provides the ip addres, then yes, it works. For us to help you we need a little more than this. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Request for Funding our Electricity
For additional financial source, may I suggest that the project license some of their artworks? I think this has been asked for so many times before, maybe you should reconsider your stand on this. Of course Theo or the OpenBSD project as a whole, or the OBSD Foundation can define which artwork is licensed for what purpose and to whom or what organization. OpenBSD may be sitting too long on this potentially lucrative asset. We have to be clear that the objective is to keep the project sustainable. What do you think? Hope this helps. On Wed, Jan 15, 2014 at 7:02 AM, Ted Unangst wrote: > On Tue, Jan 14, 2014 at 16:12, Erik Mitchell wrote: > > > I have not actively kept up with this list so forgive me if this can't > > be done, or isn't in line with the community's values, but what about > > doing a Kickstarter campaign for each OpenBSD release? Varying levels > > of support could get the different levels of swag that are already > > distributed: CD/DVD distributions, t-shirts, stickers, etc... > > > > One could also just contribute $10-$20 to be a supporter, and receive > > nothing material. > > You can do all this (and more!) on the website today. And you get > soonish delivery without having to wait until a thousand other people > donate. And the project doesn't have to pay out a cut to yet another > middleman.
Re: Request for Funding our Electricity
previously on this list Theo contributed: > The OpenBSD project uses a lot of electricity for running the > development and build machines. A number of logistical reasons > prevents us from moving the machines to another location which might > offer space/power for free, so let's not allow the conversation to go > that way. Especially if you have some land in Canada and manage to raise a significant bit extra, a Peltier energy harvesting system due to the difference in surface and sub-surface land temperature might be worth looking at to help balance the books longer term. The Aston Martin plant runs off one entirely but cost a fortune to drill a deep bore hole to get a large temperature difference, but then their building is huge and produces cars with enough power to run a town. Alternatively a small scale system building it into a wall to get the difference between the cold Canadian winter outside and warm inside might work well. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
NAT reliability in light of recent checksum changes
Hi all, I'm using OpenBSD 5.3 to provide an Alix-based home firewall. Thank you all for the commitment to elegant, well-documented software which isn't pernicious to the mental health of its users. I've a question about the new checksum changes[0], being interested in such things and having listened to Henning's presentation and poked around in the archives a little. My understanding is that checksums are now always recalculated when a header is altered, never updated.[1] Is that right and if so has this affected NAT reliability? Recalculation here would compromise reliable end-to-end transport as the payload checksum no longer covers the entire network path, and so break a basic transport layer design principle.[2][3] best, Richard. [0] http://www.openbsd.org/54.html "Reworked checksum handling for network protocols." [1] e.g. 26:45 slide 27, 'use protocol checksum offloading better' http://quigon.bsws.de/papers/2013/EuroBSDcon/mgp00027.html 30:51 slide 30, 'consequences in pf' http://quigon.bsws.de/papers/2013/EuroBSDcon/mgp00030.html https://www.youtube.com/watch?v=AymV11igbLY 'The surprising complexity of checksums in TCP/IP' [2] V. Cerf, R. Khan, IEEE Trans on Comms, Vol Com-22, No 5 May 1974 Page 3 in original emphasis. > The remainder of the packet consists of text for delivery to the > destination and a trailing check sum used for end-to-end software > verification. The GATEWAY does /not/ modify the text and merely > forwards the check sum along without computing or recomputing it. [3] Page 3. http://www.ietf.org/rfc/rfc793.txt > The TCP must recover from data that is damaged, lost, duplicated, or > delivered out of order by the internet communication system. [...] > Damage is handled by adding a checksum to each segment transmitted, > checking it at the receiver, and discarding damaged segments.
Re: Request for Funding our Electricity
On Tue, Jan 14, 2014 at 03:24:00PM -0700, Theo de Raadt wrote: > > I will take this opportunity to suggest a probably bad idea but one > > that crossed my mind nonetheless. > > > > I have not actively kept up with this list so forgive me if this can't > > be done, or isn't in line with the community's values, but what about > > doing a Kickstarter campaign for each OpenBSD release? Varying levels > > of support could get the different levels of swag that are already > > distributed: CD/DVD distributions, t-shirts, stickers, etc... > > The problem with this model is that once again > - we are the ones who need to supply more; > - we need to promising the goods; > - we are the ones who need to invest; > - we are supposed to do the extra work; > - we are supposed to take time away from coding. Who would back the KickStarter but be unwilling to donate directly to the project? The community is already here, the project already accepts donations. I don't see what KickStarter offers besides the hipster cred of running a KickStarter, and hipster cred doesn't pay electrical bills. Anyways, talk is cheap so I'm going to go make a donation now. If everyone reading this did the same this thread could die, and OpenBSD wouldn't.
Re: Request for Funding our Electricity
On Tue, Jan 14, 2014 at 16:12, Erik Mitchell wrote: > I have not actively kept up with this list so forgive me if this can't > be done, or isn't in line with the community's values, but what about > doing a Kickstarter campaign for each OpenBSD release? Varying levels > of support could get the different levels of swag that are already > distributed: CD/DVD distributions, t-shirts, stickers, etc... > > One could also just contribute $10-$20 to be a supporter, and receive > nothing material. You can do all this (and more!) on the website today. And you get soonish delivery without having to wait until a thousand other people donate. And the project doesn't have to pay out a cut to yet another middleman.
Re: Request for Funding our Electricity
There's a lot of reasons why I want to avoid this conversation, but since it's started, I'd say look at http://www.patreon.com/ for a crowdfunding model - much nicer than Kickstarters. (and a way to get people to formalize their buying of CD sets every release)
Re: Request for Funding our Electricity
> > Anyone want to suggest we hold a bake sale? > > I will take this opportunity to suggest a probably bad idea but one > that crossed my mind nonetheless. > > I have not actively kept up with this list so forgive me if this can't > be done, or isn't in line with the community's values, but what about > doing a Kickstarter campaign for each OpenBSD release? Varying levels > of support could get the different levels of swag that are already > distributed: CD/DVD distributions, t-shirts, stickers, etc... The problem with this model is that once again - we are the ones who need to supply more; - we need to promising the goods; - we are the ones who need to invest; - we are supposed to do the extra work; - we are supposed to take time away from coding. Don't we do enough? Regarding the swag. The entire OpenBSD project now probably gets 1/4 of revenue out of CD, tshirt sales, but in this model we'd have to give much of that out to people who contribute, and it will probably be less. Remember to add shipping, now paid on this end, instead of by the buyer. > One could also just contribute $10-$20 to be a supporter, and receive > nothing material. $20? To break even with the above issues, call it $100 minimum. Does it still work? Is there evidence? And once this turn process on, if it doesn't work, are we even more dead in the water? > Nodejitsu recently raised $256k with their Scalenpm campaign. I would > imagine there are enough people out there who care about OpenBSD too > whereby a significant amount of money could be raised. Would that work every year? I doubt mindshare of this sort works repeatedly.
Re: Request for Funding our Electricity
> Anyone want to suggest we hold a bake sale? I will take this opportunity to suggest a probably bad idea but one that crossed my mind nonetheless. I have not actively kept up with this list so forgive me if this can't be done, or isn't in line with the community's values, but what about doing a Kickstarter campaign for each OpenBSD release? Varying levels of support could get the different levels of swag that are already distributed: CD/DVD distributions, t-shirts, stickers, etc... One could also just contribute $10-$20 to be a supporter, and receive nothing material. Nodejitsu recently raised $256k with their Scalenpm campaign. I would imagine there are enough people out there who care about OpenBSD too whereby a significant amount of money could be raised. -Erik -- Erik K. Mitchell erik.mitch...@gmail.com
Re: Request for Funding our Electricity
On 1/14/14, Theo de Raadt wrote: >> On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck >> wrote: >> >Just to bring this issue back to the forefront. >> > >> > In light of shrinking funding, we do need to look for a source to >> > cover project expenses. If need be the OpenBSD Foundation can be >> > involved in receiving donations to cover project electrical costs. >> > >> > But the fact is right now, OpenBSD will shut down if we do not have >> > the funding to keep the lights on. >> > >> > If you or a company you know are able to assist us, it would be >> > greatly appreciated, but right now we are looking at a significant >> > funding shortfall for the upcoming year - Meaning the project won't be >> > able to cover 20 thousand dollars in electrical expenses before being >> > able to use money for other things. That sort of situation is not >> > sustainable. >> >> There's an equation that has to be satisfied here. It has a demand >> side and a supply side. You demand a certain amount of electricity and >> someone has to supply the money to pay for it. I'm going to be blunt >> here, in an effort to be helpful (it's also not foreign to the OpenBSD >> style). I get the impression that the demand for electricity is viewed >> as a given: you use what you use and people need to step up and >> provide the money to pay for it. If I'm wrong, please say so. But if >> I'm right, the demand can be adjusted. Sometimes you need to eat >> cornflakes instead of caviar. For example, I've never understood why >> this project supports the old architectures it does, considering the >> associated costs. > > The answer to that is not news. > > On a regular basis, we find real and serious bugs which affect all > platforms, but they are incidentally made visible on one of the > platforms we run, following that they are fixed. It is a harsh > reality which static and dynamic analysis tools have not yet resolved. > > Now, If you don't realize this is the reason we try to run on the > older platforms, I am sorry but you have really not tried to stay in > the loop of what makes OpenBSD a vibrant ecosystem. If you aren't in > the loop regarding this, then your mail comes off pretty darn preachy. > >> The recent discussion of a need for a replacement >> Vax for package-building illustrates that. > > The vaxes being asked for draw almost no power, but it supplies the > same benefits as the other architectures. > > Regarding shutting them down, there other social problems. > > Yes, we remove about 10 of the architectures. We'd slowly lose the > developers who like to work on those areas. They also work in other > areas, but ... I suspect they would another BSD that supports them. > >> Perhaps this is an opportunity to reassess the scope of the project >> and trim some things that can no longer be justified on a cost-benefit >> basis. > > And maybe we've been doing that assessment continually for two > decades. > >> If the choice is between shutting the project down and reducing its >> scope to something sustainable, it's a no-brainer. This project has >> made really significant contributions, both in the obvious area, >> security, but also to the art of managing and building complex >> software that is reliable. To have it go away rather than trim its >> sails in way that acknowledges reality would really be a shame. > > This project "has made"? How about "this project will continue to". > > I really love how we keep getting advice. I think you misunderstood the concept of supply and demand pointed out in the message you replied to. "We" are so used to leeching off the project, and for so long, that we feel entitled to /demand/ that you and your project /supply/ what we feel entitled to. Because of our dependence to this entitlement feeling, should anything threaten the supply of what you produce, must not be allowed. Even if "we" should need to go to our government representatives to address this threat! I can see it now: OBSD=OBama Software Distribution. It will be provided to everyone and anyone, whether or not they feel they need it. If anyone chooses to not use it, they still will be charged a "fee" for the CD set they don't need now, but /might/ need in the future. This program will be sustained by inflated CD prices (say $750 a copy), and by cutting bits of the project which will be deemed unnecessary, such as old and obsolete hardware support (VAX, Sparc, ...), stickers will be discontinued, OpenSSH will be removed from base; let's be honest about it, you really need encryption if you have something to hide (from the government). I understand they now have worked out all the glitches in their web-site, which will now host the new OBSD. Cheers, --patrick
Re: Request for Funding our Electricity
Kiril, a dedicated one purpose bank account or officially directed donations are somewhat problematic to a canadian not for profit - Normally for expenses the foundation supports we simply re-imburse the individuals for their costs from our funds. As far as the suggested "donation" meter that's an idea we'd probably like to put up - as it gets that crowdsourcing type interest going. But in this case it would likely not be 20K, more like a 150K yearly goal would be best. On Tue, Jan 14, 2014 at 2:16 PM, Kirill Bychkov wrote: > On Wed, January 15, 2014 00:03, Bob Beck wrote: >>Just to bring this issue back to the forefront. >> >> In light of shrinking funding, we do need to look for a source to >> cover project expenses. If need be the OpenBSD Foundation can be >> involved in receiving donations to cover project electrical costs. >> >> But the fact is right now, OpenBSD will shut down if we do not have >> the funding to keep the lights on. >> >> If you or a company you know are able to assist us, it would be >> greatly appreciated, but right now we are looking at a significant >> funding shortfall for the upcoming year - Meaning the project won't be >> able to cover 20 thousand dollars in electrical expenses before being >> able to use money for other things. That sort of situation is not >> sustainable. >> > > Hi. Could we collect this sum on special bank account, to gather correct sum > for covering electricity expenses? > Or OpenBSD Foundation will pay a bill from it's funds? > Simplier - should I send money to Foundation right now or should I wait info > about direct-electricity-expenses-acccount? Unfortunately I can't send $20k, > but if 200 community members send $100 each... > I hope this will help to have another year for searching a company Theo was > mentioning in his irst letter. > >> >> >> On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt >> wrote: >>> I am resending this request for funding our electricity bills because >>> it is not yet resolved. >>> >>> We really need even more funding beyond that, because otherwise all of >>> this is simply unsustainable. This request is the smallest we can >>> make. >>> >>> --- >>> >>> Hi everyone. >>> >>> The OpenBSD project uses a lot of electricity for running the >>> development and build machines. A number of logistical reasons >>> prevents us from moving the machines to another location which might >>> offer space/power for free, so let's not allow the conversation to go >>> that way. >>> >>> We are looking for a Canadian company who will take on our electrical >>> expenses -- on their books, rather than on our books. We would be >>> happiest to find someone who will do this on an annual recurring >>> basis. >>> >>> That way the various OpenBSD efforts can be supported, yet written off >>> as an off-site operations cost by such a company. If we reduce this >>> cost, it will leave more money for other parts of the project. >>> >>> We think that a Canadian company is the best choice for accounting >>> reasons. If a company in some other jurisdiction feels they can also >>> do this successfully, we'd be very happy to hear from them as well. >>> >>> I am not going to disclose the actual numbers here. Please contact me >>> for details if serious. >>> >>> Thanks.
PPPoE "ip unnumbered"
Hi, Is it possible to create an IP unnumbered setup with PPPoE on OpenBSD? Kind regards, Martijn Rijkeboer
bwi0: intr fatal TX/RX ([01]) error 0x00001000 (continuously streaming)
Hello! Running 5.4-RELEASE/macppc on a Mac PowerBook G4, attempting to interact with the built-in bwi(4) card results in badness. I have installed bwi-firmware-1.4p2 from ports; the card is detected, but attempting to run "ifconfig bwi0 scan" or "ifconfig bwi0 up" results in the error message in the subject line (with either an 0 or a 1) streaming continuously on the console and locking up the machine (any SSH sessions over the wired interface also freeze as soon as this command is issued.) I'm happy to try -current or any patches anyone might have knocking about, or to provide any additional requested information. Thanks much for any help! dmesg follows: Jan 14 16:15:01 atropine /bsd: [ using 500456 bytes of bsd ELF symbol table ] Jan 14 16:15:01 atropine /bsd: console out [ATY,Jasper_A]console in [keyboard] USB and ADB found, using ADB Jan 14 16:15:01 atropine /bsd: using parent ATY,JasperParent:: memaddr b800 size 800, : consaddr b8008000, : ioaddr b002, size 2: memtag 8000, iotag 8000: width 1280 linebytes 1280 height 854 depth 8 Jan 14 16:15:01 atropine /bsd: Copyright (c) 1982, 1986, 1989, 1991, 1993 Jan 14 16:15:01 atropine /bsd: The Regents of the University of California. All rights reserved. Jan 14 16:15:01 atropine /bsd: Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org Jan 14 16:15:01 atropine /bsd: Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org Jan 14 16:15:01 atropine /bsd: OpenBSD 5.4 (GENERIC) #32: Tue Jul 30 14:18:00 MDT 2013 Jan 14 16:15:01 atropine /bsd: dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC Jan 14 16:15:01 atropine /bsd: real mem = 2147483648 (2048MB) Jan 14 16:15:01 atropine /bsd: avail mem = 2079158272 (1982MB) Jan 14 16:15:01 atropine /bsd: mainbus0 at root: model PowerBook5,4 Jan 14 16:15:01 atropine /bsd: cpu0 at mainbus0: 7447A (Revision 0x101): 1499 MHz: 512KB L2 cache Jan 14 16:15:01 atropine /bsd: mem0 at mainbus0 Jan 14 16:15:01 atropine /bsd: spdmem0 at mem0: 1GB DDR SDRAM non-parity PC2700CL2.5 Jan 14 16:15:01 atropine /bsd: spdmem1 at mem0: 1GB DDR SDRAM non-parity PC2700CL2.5 Jan 14 16:15:01 atropine /bsd: memc0 at mainbus0: uni-n rev 0xd2 Jan 14 16:15:01 atropine /bsd: "hw-clock" at memc0 not configured Jan 14 16:15:01 atropine /bsd: kiic0 at memc0 offset 0xf8001000 Jan 14 16:15:01 atropine /bsd: iic0 at kiic0 Jan 14 16:15:01 atropine /bsd: adt0 at iic0 addr 0xae: adt7460 rev 0x6a Jan 14 16:15:01 atropine /bsd: mpcpcibr0 at mainbus0 pci: uni-north Jan 14 16:15:01 atropine /bsd: pci0 at mpcpcibr0 bus 0 Jan 14 16:15:01 atropine /bsd: pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 Jan 14 16:15:01 atropine /bsd: appleagp0 at pchb0 Jan 14 16:15:01 atropine /bsd: agp0 at appleagp0: aperture at 0x0, size 0x1000 Jan 14 16:15:01 atropine /bsd: vgafb0 at pci0 dev 16 function 0 "ATI Radeon Mobility M10" rev 0x00, mmio Jan 14 16:15:01 atropine /bsd: wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) Jan 14 16:15:01 atropine /bsd: wsdisplay0: screen 1-5 added (std, vt100 emulation) Jan 14 16:15:01 atropine /bsd: mpcpcibr1 at mainbus0 pci: uni-north Jan 14 16:15:01 atropine /bsd: pci1 at mpcpcibr1 bus 0 Jan 14 16:15:01 atropine /bsd: pchb1 at pci1 dev 11 function 0 "Apple UniNorth PCI" rev 0x00 Jan 14 16:15:01 atropine /bsd: bwi0 at pci1 dev 18 function 0 "Broadcom BCM4306" rev 0x03: irq 52, address 00:11:24:23:3e:df Jan 14 16:15:01 atropine /bsd: cbb0 at pci1 dev 19 function 0 "TI PCI1510 CardBus" rev 0x00: irq 53 Jan 14 16:15:01 atropine /bsd: macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 Jan 14 16:15:01 atropine /bsd: openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE Jan 14 16:15:01 atropine /bsd: macgpio0 at macobio0 offset 0x50 Jan 14 16:15:01 atropine /bsd: "modem-reset" at macgpio0 offset 0x1d not configured Jan 14 16:15:01 atropine /bsd: "modem-power" at macgpio0 offset 0x1c not configured Jan 14 16:15:01 atropine /bsd: macgpio1 at macgpio0 offset 0x9: irq 47 Jan 14 16:15:01 atropine /bsd: "programmer-switch" at macgpio0 offset 0x11 not configured Jan 14 16:15:01 atropine /bsd: dfs0 at macgpio0 offset 0x6b: speeds: 1499, 749 MHz Jan 14 16:15:01 atropine /bsd: "gpio4" at macgpio0 offset 0x1e not configured Jan 14 16:15:01 atropine /bsd: "gpio5" at macgpio0 offset 0x6f not configured Jan 14 16:15:01 atropine /bsd: "gpio6" at macgpio0 offset 0x70 not configured Jan 14 16:15:01 atropine /bsd: "extint-gpio4" at macgpio0 offset 0x5c not configured Jan 14 16:15:01 atropine /bsd: "gpio11" at macgpio0 offset 0x75 not configured Jan 14 16:15:01 atropine /bsd: "extint-gpio15" at macgpio0 offset 0x67 not configured Jan 14 16:15:01 atropine /bsd: "escc-legacy" at macobio0 offset 0x12000 not configured Jan 14 16:15:01 atropine /bsd: zsc0 at macobio0 offset 0x13000: irq 22,23 Jan 14 16:15:01 atropine /bsd: zstty0 at zsc0 channel 0 Jan 14 16:15:01 atropine /bsd: zstty1 at zsc0 channel 1 Jan 14 16:15:01 atropine /bsd: aoa0
Re: Request for Funding our Electricity
On Wed, January 15, 2014 00:03, Bob Beck wrote: >Just to bring this issue back to the forefront. > > In light of shrinking funding, we do need to look for a source to > cover project expenses. If need be the OpenBSD Foundation can be > involved in receiving donations to cover project electrical costs. > > But the fact is right now, OpenBSD will shut down if we do not have > the funding to keep the lights on. > > If you or a company you know are able to assist us, it would be > greatly appreciated, but right now we are looking at a significant > funding shortfall for the upcoming year - Meaning the project won't be > able to cover 20 thousand dollars in electrical expenses before being > able to use money for other things. That sort of situation is not > sustainable. > Hi. Could we collect this sum on special bank account, to gather correct sum for covering electricity expenses? Or OpenBSD Foundation will pay a bill from it's funds? Simplier - should I send money to Foundation right now or should I wait info about direct-electricity-expenses-acccount? Unfortunately I can't send $20k, but if 200 community members send $100 each... I hope this will help to have another year for searching a company Theo was mentioning in his irst letter. > > > On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt > wrote: >> I am resending this request for funding our electricity bills because >> it is not yet resolved. >> >> We really need even more funding beyond that, because otherwise all of >> this is simply unsustainable. This request is the smallest we can >> make. >> >> --- >> >> Hi everyone. >> >> The OpenBSD project uses a lot of electricity for running the >> development and build machines. A number of logistical reasons >> prevents us from moving the machines to another location which might >> offer space/power for free, so let's not allow the conversation to go >> that way. >> >> We are looking for a Canadian company who will take on our electrical >> expenses -- on their books, rather than on our books. We would be >> happiest to find someone who will do this on an annual recurring >> basis. >> >> That way the various OpenBSD efforts can be supported, yet written off >> as an off-site operations cost by such a company. If we reduce this >> cost, it will leave more money for other parts of the project. >> >> We think that a Canadian company is the best choice for accounting >> reasons. If a company in some other jurisdiction feels they can also >> do this successfully, we'd be very happy to hear from them as well. >> >> I am not going to disclose the actual numbers here. Please contact me >> for details if serious. >> >> Thanks.
Re: Bake Sale
--- Theo de Raadt wrote: > Anyone want to suggest we hold a bake sale? I understand there is a market for brownies in Colorado and Washington state. Ken Hendrickson
Re: Request for Funding our Electricity
> Yes, we remove about 10 of the architectures. We'd slowly lose the > developers who like to work on those areas. They also work in other > areas, but ... I suspect they would another BSD that supports them. Darn' tootin'! > Anyone want to suggest we hold a bake sale? Make that a lo-carb bake sale.
Re: Request for Funding our Electricity
How about we hold a bake sale? On Tue, Jan 14, 2014 at 2:56 PM, Theo de Raadt wrote: > > On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck > wrote: > > >Just to bring this issue back to the forefront. > > > > > > In light of shrinking funding, we do need to look for a source to > > > cover project expenses. If need be the OpenBSD Foundation can be > > > involved in receiving donations to cover project electrical costs. > > > > > > But the fact is right now, OpenBSD will shut down if we do not have > > > the funding to keep the lights on. > > > > > > If you or a company you know are able to assist us, it would be > > > greatly appreciated, but right now we are looking at a significant > > > funding shortfall for the upcoming year - Meaning the project won't be > > > able to cover 20 thousand dollars in electrical expenses before being > > > able to use money for other things. That sort of situation is not > > > sustainable. > > > > There's an equation that has to be satisfied here. It has a demand > > side and a supply side. You demand a certain amount of electricity and > > someone has to supply the money to pay for it. I'm going to be blunt > > here, in an effort to be helpful (it's also not foreign to the OpenBSD > > style). I get the impression that the demand for electricity is viewed > > as a given: you use what you use and people need to step up and > > provide the money to pay for it. If I'm wrong, please say so. But if > > I'm right, the demand can be adjusted. Sometimes you need to eat > > cornflakes instead of caviar. For example, I've never understood why > > this project supports the old architectures it does, considering the > > associated costs. > > The answer to that is not news. > > On a regular basis, we find real and serious bugs which affect all > platforms, but they are incidentally made visible on one of the > platforms we run, following that they are fixed. It is a harsh > reality which static and dynamic analysis tools have not yet resolved. > > Now, If you don't realize this is the reason we try to run on the > older platforms, I am sorry but you have really not tried to stay in > the loop of what makes OpenBSD a vibrant ecosystem. If you aren't in > the loop regarding this, then your mail comes off pretty darn preachy. > > > The recent discussion of a need for a replacement > > Vax for package-building illustrates that. > > The vaxes being asked for draw almost no power, but it supplies the > same benefits as the other architectures. > > Regarding shutting them down, there other social problems. > > Yes, we remove about 10 of the architectures. We'd slowly lose the > developers who like to work on those areas. They also work in other > areas, but ... I suspect they would another BSD that supports them. > > > Perhaps this is an opportunity to reassess the scope of the project > > and trim some things that can no longer be justified on a cost-benefit > > basis. > > And maybe we've been doing that assessment continually for two > decades. > > > If the choice is between shutting the project down and reducing its > > scope to something sustainable, it's a no-brainer. This project has > > made really significant contributions, both in the obvious area, > > security, but also to the art of managing and building complex > > software that is reliable. To have it go away rather than trim its > > sails in way that acknowledges reality would really be a shame. > > This project "has made"? How about "this project will continue to". > > I really love how we keep getting advice. > > Anyone want to suggest we hold a bake sale?
Re: Request for Funding our Electricity
> On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck wrote: > >Just to bring this issue back to the forefront. > > > > In light of shrinking funding, we do need to look for a source to > > cover project expenses. If need be the OpenBSD Foundation can be > > involved in receiving donations to cover project electrical costs. > > > > But the fact is right now, OpenBSD will shut down if we do not have > > the funding to keep the lights on. > > > > If you or a company you know are able to assist us, it would be > > greatly appreciated, but right now we are looking at a significant > > funding shortfall for the upcoming year - Meaning the project won't be > > able to cover 20 thousand dollars in electrical expenses before being > > able to use money for other things. That sort of situation is not > > sustainable. > > There's an equation that has to be satisfied here. It has a demand > side and a supply side. You demand a certain amount of electricity and > someone has to supply the money to pay for it. I'm going to be blunt > here, in an effort to be helpful (it's also not foreign to the OpenBSD > style). I get the impression that the demand for electricity is viewed > as a given: you use what you use and people need to step up and > provide the money to pay for it. If I'm wrong, please say so. But if > I'm right, the demand can be adjusted. Sometimes you need to eat > cornflakes instead of caviar. For example, I've never understood why > this project supports the old architectures it does, considering the > associated costs. The answer to that is not news. On a regular basis, we find real and serious bugs which affect all platforms, but they are incidentally made visible on one of the platforms we run, following that they are fixed. It is a harsh reality which static and dynamic analysis tools have not yet resolved. Now, If you don't realize this is the reason we try to run on the older platforms, I am sorry but you have really not tried to stay in the loop of what makes OpenBSD a vibrant ecosystem. If you aren't in the loop regarding this, then your mail comes off pretty darn preachy. > The recent discussion of a need for a replacement > Vax for package-building illustrates that. The vaxes being asked for draw almost no power, but it supplies the same benefits as the other architectures. Regarding shutting them down, there other social problems. Yes, we remove about 10 of the architectures. We'd slowly lose the developers who like to work on those areas. They also work in other areas, but ... I suspect they would another BSD that supports them. > Perhaps this is an opportunity to reassess the scope of the project > and trim some things that can no longer be justified on a cost-benefit > basis. And maybe we've been doing that assessment continually for two decades. > If the choice is between shutting the project down and reducing its > scope to something sustainable, it's a no-brainer. This project has > made really significant contributions, both in the obvious area, > security, but also to the art of managing and building complex > software that is reliable. To have it go away rather than trim its > sails in way that acknowledges reality would really be a shame. This project "has made"? How about "this project will continue to". I really love how we keep getting advice. Anyone want to suggest we hold a bake sale?
Re: Request for Funding our Electricity
On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck wrote: >Just to bring this issue back to the forefront. > > In light of shrinking funding, we do need to look for a source to > cover project expenses. If need be the OpenBSD Foundation can be > involved in receiving donations to cover project electrical costs. > > But the fact is right now, OpenBSD will shut down if we do not have > the funding to keep the lights on. > > If you or a company you know are able to assist us, it would be > greatly appreciated, but right now we are looking at a significant > funding shortfall for the upcoming year - Meaning the project won't be > able to cover 20 thousand dollars in electrical expenses before being > able to use money for other things. That sort of situation is not > sustainable. There's an equation that has to be satisfied here. It has a demand side and a supply side. You demand a certain amount of electricity and someone has to supply the money to pay for it. I'm going to be blunt here, in an effort to be helpful (it's also not foreign to the OpenBSD style). I get the impression that the demand for electricity is viewed as a given: you use what you use and people need to step up and provide the money to pay for it. If I'm wrong, please say so. But if I'm right, the demand can be adjusted. Sometimes you need to eat cornflakes instead of caviar. For example, I've never understood why this project supports the old architectures it does, considering the associated costs. The recent discussion of a need for a replacement Vax for package-building illustrates that. Perhaps this is an opportunity to reassess the scope of the project and trim some things that can no longer be justified on a cost-benefit basis. If the choice is between shutting the project down and reducing its scope to something sustainable, it's a no-brainer. This project has made really significant contributions, both in the obvious area, security, but also to the art of managing and building complex software that is reliable. To have it go away rather than trim its sails in way that acknowledges reality would really be a shame. /Don Allen > > > > > On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt > wrote: >> I am resending this request for funding our electricity bills because >> it is not yet resolved. >> >> We really need even more funding beyond that, because otherwise all of >> this is simply unsustainable. This request is the smallest we can >> make. >> >> --- >> >> Hi everyone. >> >> The OpenBSD project uses a lot of electricity for running the >> development and build machines. A number of logistical reasons >> prevents us from moving the machines to another location which might >> offer space/power for free, so let's not allow the conversation to go >> that way. >> >> We are looking for a Canadian company who will take on our electrical >> expenses -- on their books, rather than on our books. We would be >> happiest to find someone who will do this on an annual recurring >> basis. >> >> That way the various OpenBSD efforts can be supported, yet written off >> as an off-site operations cost by such a company. If we reduce this >> cost, it will leave more money for other parts of the project. >> >> We think that a Canadian company is the best choice for accounting >> reasons. If a company in some other jurisdiction feels they can also >> do this successfully, we'd be very happy to hear from them as well. >> >> I am not going to disclose the actual numbers here. Please contact me >> for details if serious. >> >> Thanks.
tmux cwd - console vs xterm
Not so long ago, the cwd functionality was removed from tmux. http://marc.info/?l=openbsd-misc&m=138270549910047&w=2 With the current i386 snapshot, tmux behaves as follows: Opening a new window with prefix-c in xterm creates a new window and starts a shell in $HOME Opening a new window with prefix-c on the console creates a new window and starts a shell in the current directory. Is that intended? Jan
Re: Request for Funding our Electricity
And actually, if you're reading this, you can help by passing this on to people you know *off these lists*. When we post to these mailing lists saying these things we are asking for your help to get the word out to people who support open source projects. Those people are not necessarily here, and often, you (the people who use it and work with it) need to make the case to them that their support is important - far better that explanation comes from you rather than someone they don't know. -Bob On Tue, Jan 14, 2014 at 1:03 PM, Bob Beck wrote: >Just to bring this issue back to the forefront. > > In light of shrinking funding, we do need to look for a source to > cover project expenses. If need be the OpenBSD Foundation can be > involved in receiving donations to cover project electrical costs. > > But the fact is right now, OpenBSD will shut down if we do not have > the funding to keep the lights on. > > If you or a company you know are able to assist us, it would be > greatly appreciated, but right now we are looking at a significant > funding shortfall for the upcoming year - Meaning the project won't be > able to cover 20 thousand dollars in electrical expenses before being > able to use money for other things. That sort of situation is not > sustainable. > > > > > On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt > wrote: >> I am resending this request for funding our electricity bills because >> it is not yet resolved. >> >> We really need even more funding beyond that, because otherwise all of >> this is simply unsustainable. This request is the smallest we can >> make. >> >> --- >> >> Hi everyone. >> >> The OpenBSD project uses a lot of electricity for running the >> development and build machines. A number of logistical reasons >> prevents us from moving the machines to another location which might >> offer space/power for free, so let's not allow the conversation to go >> that way. >> >> We are looking for a Canadian company who will take on our electrical >> expenses -- on their books, rather than on our books. We would be >> happiest to find someone who will do this on an annual recurring >> basis. >> >> That way the various OpenBSD efforts can be supported, yet written off >> as an off-site operations cost by such a company. If we reduce this >> cost, it will leave more money for other parts of the project. >> >> We think that a Canadian company is the best choice for accounting >> reasons. If a company in some other jurisdiction feels they can also >> do this successfully, we'd be very happy to hear from them as well. >> >> I am not going to disclose the actual numbers here. Please contact me >> for details if serious. >> >> Thanks.
Re: Request for Funding our Electricity
Just to bring this issue back to the forefront. In light of shrinking funding, we do need to look for a source to cover project expenses. If need be the OpenBSD Foundation can be involved in receiving donations to cover project electrical costs. But the fact is right now, OpenBSD will shut down if we do not have the funding to keep the lights on. If you or a company you know are able to assist us, it would be greatly appreciated, but right now we are looking at a significant funding shortfall for the upcoming year - Meaning the project won't be able to cover 20 thousand dollars in electrical expenses before being able to use money for other things. That sort of situation is not sustainable. On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt wrote: > I am resending this request for funding our electricity bills because > it is not yet resolved. > > We really need even more funding beyond that, because otherwise all of > this is simply unsustainable. This request is the smallest we can > make. > > --- > > Hi everyone. > > The OpenBSD project uses a lot of electricity for running the > development and build machines. A number of logistical reasons > prevents us from moving the machines to another location which might > offer space/power for free, so let's not allow the conversation to go > that way. > > We are looking for a Canadian company who will take on our electrical > expenses -- on their books, rather than on our books. We would be > happiest to find someone who will do this on an annual recurring > basis. > > That way the various OpenBSD efforts can be supported, yet written off > as an off-site operations cost by such a company. If we reduce this > cost, it will leave more money for other parts of the project. > > We think that a Canadian company is the best choice for accounting > reasons. If a company in some other jurisdiction feels they can also > do this successfully, we'd be very happy to hear from them as well. > > I am not going to disclose the actual numbers here. Please contact me > for details if serious. > > Thanks.
Re: popa3d removed from base - what do people recommend?
previously on this list Артур Истомин contributed: > > > I think pop3 is dead but recently there was a mail in tech@ > > > stating Sunil Nimmagadda develops pop3 daemon closed to > > > OpenBSD standards. > > > > That's a good point. I don't like leaving mails on the server for more than > > a > > day or so, but I don't see why I can't emulate this behavior on IMAP. I had > > originally chosen POP3 because OpenBSD came with it batteries-included. > > > > There's still some research I need to do on my own, but it does look like > > dovecot fits the OpenBSD mentality of security first in development. > > dovecot has more vulns. than other open source imap implementations all > together. > > Dovecot: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dovecot (31) > Cyrus IMAP https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Cyrus-imap > (3) > etc.. I don't think that paints an accurate picture in this case. You will see more for cyrus listed on osvdb.org than mitre many of which from a quick look are more worrying than dovecots. I believe Dovecot is used by more people and so is more likely to have bugs found and still offers a $1000 for any root exploit. Perhaps you know both better than me as I know Dovecot quite well but not Cyrus but from a quick look at the documentation and website. Cyrus seems to have far less pro-active security features that some of the vulnerabilities simply bypass. Good to know it has competition though, I've only ever looked at Cyrus-sasl. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
PPPoE problem
Hi, I'm trying to setup a PPPoE connection to my ISP (solcon.nl). I've read pppoe(4) and pppoe(8) and got the following configuration: cat /etc/hostname.pppoe0 inet 0.0.0.0 255.255.255.255 NONE \ pppoedev em2 authproto pap \ authname '@solcon.net' authkey '' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 cat /etc/hostname.em2 up According to my ISP I should specify my IP-address and netmask which makes the following: cat /etc/hostname.pppoe0 inet 123.123.123.1 255.255.255.128 NONE \ pppoedev em2 authproto pap \ authname '@solcon.net' authkey '' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 In both cases I'm getting "pppoe0: pap failure". This seems to indicate that the authentications is wrong, but according to my ISP they don't see any traffic from me to their radius server and we double checked the username and password. Since they don't support OpenBSD they gave me a sample config for Cisco: interface FastEthernet0/0 description LAN klant ip address 123.123.123.1 255.255.255.128 duplex auto speed auto no keepalive ! interface FastEthernet0/1 description WAN no ip address duplex full speed 100 pppoe enable pppoe-client dial-pool-number 1 ! interface Dialer0 ip unnumbered FastEthernet0/0 encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer idle-time dialer-group 1 no cdp enable ppp authentication pap callin ppp pap sent-username @solcon.net password ! ip route 0.0.0.0 0.0.0.0 Dialer0 permanent Any suggestions on what I'm doing wrong or how to configure this? Kind regards, Martijn Rijkeboer
Re: Virtualize or bare-metal?
Em 14-01-2014 06:49, Renaud Allard escreveu: > > To be fair, virtualizing stuff without a common shared storage is a > little bit useless. The biggest power of virtualization is to be able > to move VMs between physical hosts or even powering on physical hosts > when you need more power. > > But security wise, just to cite Theo: > x86 virtualization is about basically placing another nearly full > kernel, full of new bugs, on top of a nasty x86 architecture which > barely has correct page protection. Then running your operating system > on the other side of this brand new pile of shit. > > You are absolutely deluded, if not stupid, if you think that a > worldwide collection of software engineers who can't write operating > systems or applications without security holes, can then turn around > and suddenly write virtualization layers without security holes. I've never said that virtualization is secure. Some recent work on the field even prove that virtualization is almost impossible to do in a secure way. See the Gal Diskin talk on 30c3. But the demand is ever rising and power and cooling costs go along. That's why I use virtualization, not only it provides a better usage of resources, but it reduces the power bill. And in a world that is going to face more and more blackouts in the near future, that is a great thing. I've reduced my 10 server farm to just two, using 1/5 of the power that I used before, and faster. You can easily improve the hardware of two machines. But try improving the hardware of 10, spending the same amount of money. That's why I didn't blink when choosing to virtualize everything. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: popa3d removed from base - what do people recommend?
On Mon, Jan 06, 2014 at 01:10:09PM -0500, John Smith wrote: > > I think pop3 is dead but recently there was a mail in tech@ > > stating Sunil Nimmagadda develops pop3 daemon closed to > > OpenBSD standards. > > That's a good point. I don't like leaving mails on the server for more than a > day or so, but I don't see why I can't emulate this behavior on IMAP. I had > originally chosen POP3 because OpenBSD came with it batteries-included. > > There's still some research I need to do on my own, but it does look like > dovecot fits the OpenBSD mentality of security first in development. dovecot has more vulns. than other open source imap implementations all together. Dovecot: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dovecot (31) Cyrus IMAP https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Cyrus-imap (3) etc..
[spamd] longer retention of blacklist entries
OBSOLETE WHEN UA.CA IMPLEMENTS NEW SPAMLOGD Because traplist.gz sometimes expires hosts that are still sending spam to the world, I'd like to keep these addresses tarpitted for a while after they are removed, say 24 hours. This logic doesn't apply to the nixspam list because it contains addresses of legitimate hosts that temporarily send spam. (I've found that keeping these addresses tarpitted longer is counterproductive.) This blacklist specifies single addresses (not blocks), so I could add/update all these addresses as TRAPPED entries in /var/db/spamd, but that would make the database quite unwieldy and also makes it impossible to see in the log files which blacklist it was. So I modified spamdb(8) to add an -f option for specifying an alternate db file and an -e option for removing all expired entries. Then I created a script that is called by cron every half hour (:15 and :45) and does the following: - sleep randomly 0..5 minutes to spread the peak load - fetch traplist.gz using wget/curl (because ftp(1) doesn't do HTTP timestamping) - add/update the addresses from this list in a separate db file - remove expired db entries - dump the db into a new blacklist file - run spamd-setup(8), aggregating this new file (and a few others) I've been running this set-up for a few months now. The DB manipulation places a significant load on the server, but I believe that further optimizations are possible. Does anyone feel the need to comment on this approach? -- Boudewijn Dijkstra Indes-IDS B.V. +31 345 545 535
undefined __res_state using libbind
Hi, following Stuart's suggestion to use libbind, I recompiled and linked Pantomime. I added: ADDITIONAL_LDFLAGS += -lbind ADDITIONAL_LDFLAGS += -Wl,-L/usr/local/lib/libbind -Wl,-R/usr/local/lib/libbind ADDITIONAL_INCLUDE_DIRS += -I/usr/local/include/bind I confirm that the additional include gets usied during compilation and then check that the generated library is linked against libbind: $ ldd /Local/Library/Libraries/libPantomime.so /Local/Library/Libraries/libPantomime.so: StartEnd Type Open Ref GrpRef Name 0d0d1000 2d109000 dlib 10 0 /Local/Library/Frameworks/Pantomime.framework/Ver sions/1.2/libPantomime.so.1.2.0 070fa000 27107000 rlib 01 0 /usr/lib/libssl.so.19.0 0c7ad000 2c7ec000 rlib 01 0 /usr/lib/libcrypto.so.22.0 0a763000 2a76b000 rlib 01 0 /usr/local/lib/libbind/libbind.so.3.0 0755a000 2755f000 rlib 02 0 /usr/lib/libpthread.so.17.3 I hope this is enough and correct? When I link GNUMail against Pantomine I get this though: Making all for app GNUMail... Linking app GNUMail ... /usr/local/lib/libgmp.so.9.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libgcrypt.so.18.0: warning: stpcpy() is dangerous GNU crap; don't use it /usr/local/lib/libobjc.so.5.0: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libgnutls.so.39.7: warning: strcat() is almost always misused, please use strlcat() /Local/Library/Libraries/libPantomime.so.1.2: warning: sprintf() is often misused, please use snprintf() /Local/Library/Libraries/libPantomime.so.1.2: undefined reference to `__res_state' collect2: error: ld returned 1 exit status gmake[3]: *** [GNUMail.app/./GNUMail] Error 1 please note that I added -Wl,-R/usr/local/lib/libbind so I do not expect to need to add anything when buidling GNUmail. Just for the sake, I tried, but it doesn't help. libbind doesn't export a __res_state symbol! But why is present anyway? Pantomime code doesn't reference it explicitely, it uses _res, nothing else. So I suppose it comes from resolv.h Thanks, Riccardo
F954-6893-EAA5
accept -- -- Josef Weissacher weissacher.jo...@gmail.com --
[no subject]
unsubscribe misc@openbsd.org
Re: Virtualize or bare-metal?
On 01/14/2014 05:49 AM, Giancarlo Razzolini wrote: Em 14-01-2014 01:11, Christopher Ahrens escreveu: What I meant by bare-metal was if I should run a bunch of services on the same installation of OpenBSD. I've run in the same physical space issue with my company servers and didn't think twice to use virtualization. But, as pointed by others, you could easily accommodate all your services into one openbsd server with chroot's. But I disagree when they compare chroot directly with a vm hypervisor, because there are many things it can do, that a chroot can't. I've been using linux with qemu/kvm. Lots of pci devices passthrough's that work like a charm (there are potential security issues, worth noting). I believe that the other obvious choice is Xen. I would not go with virtualbox. And Vmware is expensive. Qemu/kvm tights nicely into the system so it's my choice. You should make your own choice. Cheers, To be fair, virtualizing stuff without a common shared storage is a little bit useless. The biggest power of virtualization is to be able to move VMs between physical hosts or even powering on physical hosts when you need more power. But security wise, just to cite Theo: x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
Re: libbind - server list
On Mon, Jan 13, 2014 at 09:36:03AM +, Stuart Henderson wrote:
> On 2014-01-12, Riccardo Mottola wrote:
> You must use libbind's headers, too: -I/usr/local/include/libbind
>
> It would probably make sense to apply the diff suggested in that thread
> though, as it fixes this case and I don't see a downside (it isn't enough
> for some programs which grovel deeper in struct _res, e.g. mtr, but it
> seems it fixes enough common cases to be useful).
>
> Here's a complete diff including tedu's suggestion.
> Eric, what do you think?
I can't test right now, but it looks ok. However, note that the entries
will not be updated on resolv.conf change, unless the caller resets the
RES_INIT flag.
If it fixes the issue it can go in.
Eric.
>
> Index: asr/res_init.c
> ===
> RCS file: /cvs/src/lib/libc/asr/res_init.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 res_init.c
> --- asr/res_init.c27 May 2013 17:31:01 - 1.2
> +++ asr/res_init.c13 Jan 2014 09:18:57 -
> @@ -37,6 +37,7 @@ res_init(void)
> {
> _THREAD_PRIVATE_MUTEX(init);
> struct asr_ctx *ac;
> + int i;
>
> ac = asr_use_resolver(NULL);
>
> @@ -55,6 +56,10 @@ res_init(void)
> strlcpy(_res.lookups, ac->ac_db, sizeof(_res.lookups));
>
> _res.nscount = ac->ac_nscount;
> + for (i = 0; i < ac->ac_nscount; i++) {
> + memcpy(&_res.nsaddr_list[i], ac->ac_ns[i],
> + ac->ac_ns[i]->sa_len);
> + }
> _res.options |= RES_INIT;
> }
> _THREAD_PRIVATE_MUTEX_UNLOCK(init);
