BSD Podcast
There's a new BSD podcast that's just started. First episode was really good, thought I'd share with the list. Interviews, tutorials, news, lots of fun stuff. http://www.bsdnow.tv/about Our very own phessler@ is the first guest.
Re: A suggestion for snapshots
> On Fri, Sep 6, 2013 at 7:14 AM, Lars Engblom > wrote: > > > Quite often the snapshot of the packages and the base system are out of > > sync, because naturally, the base has to be built before packages. > > > > For example in this moment, as I write this, Firefox can not be installed > > in a new system installed from snapshots, as the packages are compiled > > against an older snapshot (amd64) > > > > If there are just space on the ftp servers, I would suggest keeping two > > snapshots: one complete with both base and packages (always in sync) and > > one with just the newest base. This would make life easier for people > > following snapshots. > > > > Regards, > > Lasse > > > > > The problem with ports is that even with a build farm, the ports guy has to > make sure dpb runs to the end. In the best case, a dpb run WITHOUT problems > to the end takes atleast a day with a fast quad core machine. gcc4, JDK 1.6 > + 1.7, GTK+2, GTK+3, Qt4, Webkit, Firefox are some of the worst ports in > terms of build time and the largest offender Libreoffice which alone takes > 4-6 hrs of all quad cores (Xeon E3-1230v2 3.3GHz). I might have missed some > offenders, I just built a subset, experienced porters who handle the whole > tree know better than me which ones are also worthy candidates. > > Finding and fixing port problems takes a minimum of 2 and I am guessing > typically 4 days to pump out a wholly built ports tree, on a extremely fast > arch like amd64. By which time the userland, kernel and xenocara have > changed a lot underneath. Hence, you get these mismatches from time to > time. It is not catastrophic, solution is to wait for the next snap. Even > if the ports build machine untars userland, kernel, xenocara, running dpb > again may force rebuilds or sometimes not. Anyone want to pay for a faster network link? Step up -- then we can solve this problem easily.
Re: php sending mail via sendmail
I did the tcpdump and I think the following should be the reason?
---
500 5.5.1 Command unrecognized: "AUTH LOGIN"..
---
it tries to open the session with:
---
250- Hello www@ [x.x.x.x], pleased to meet
you..250-ENHANCEDSTATUSCODES..250-PIPELINING..250-8BITMIME..250-SIZE..250-DSN..250-ETRN..250-DELIVERBY..250HELP..
---
On Thu, Sep 5, 2013 at 2:18 PM, Stuart Henderson wrote:
> On 2013-09-02, Tony Berth wrote:
> > well the script does talk to google mail correctly so somehow it should
> > work.
>
> If the script is talking to google mail, it is going to be making
> SMTP connections directly itself. Given the log entry you showed, I would
> probably try sniffing the TCP connection (maybe something like
> "tcpdump -A -s 1500 -i lo0 port 25" will do).
>
> > I think all these open source php based solutions use the same way to
>
> > send e-mails.
>
> No, they don't.
>
> Sending mail from PHP is a right mess, there is the mail() function
> but it's rather limited (on unix, it just pipes to a program and can't
> do smtp-auth), also some server hosts disable it, so in practice most
> larger PHP apps have another way of sending mail where they either
> execute sendmail, or handle the socket connections themselves, or use a
> library (phpmailer etc).
> @owner ${DRUPAL_OWNER}
Re: A suggestion for snapshots
On Fri, Sep 6, 2013 at 7:14 AM, Lars Engblom wrote: > Quite often the snapshot of the packages and the base system are out of > sync, because naturally, the base has to be built before packages. > > For example in this moment, as I write this, Firefox can not be installed > in a new system installed from snapshots, as the packages are compiled > against an older snapshot (amd64) > > If there are just space on the ftp servers, I would suggest keeping two > snapshots: one complete with both base and packages (always in sync) and > one with just the newest base. This would make life easier for people > following snapshots. > > Regards, > Lasse > > The problem with ports is that even with a build farm, the ports guy has to make sure dpb runs to the end. In the best case, a dpb run WITHOUT problems to the end takes atleast a day with a fast quad core machine. gcc4, JDK 1.6 + 1.7, GTK+2, GTK+3, Qt4, Webkit, Firefox are some of the worst ports in terms of build time and the largest offender Libreoffice which alone takes 4-6 hrs of all quad cores (Xeon E3-1230v2 3.3GHz). I might have missed some offenders, I just built a subset, experienced porters who handle the whole tree know better than me which ones are also worthy candidates. Finding and fixing port problems takes a minimum of 2 and I am guessing typically 4 days to pump out a wholly built ports tree, on a extremely fast arch like amd64. By which time the userland, kernel and xenocara have changed a lot underneath. Hence, you get these mismatches from time to time. It is not catastrophic, solution is to wait for the next snap. Even if the ports build machine untars userland, kernel, xenocara, running dpb again may force rebuilds or sometimes not.
Re: ISAKMPD NAT/Traversal
On 2013-09-06, Christoph Leser wrote: > Hello, list, > > from a remark by Stuart Henderson on an older thread > http://marc.info/?l=openbsd-misc&m=134849 788026722&w=2 back in September > 2012,I understood that NAT-T support in openBSD was not complete at that time, > especially the handling of the 'ENCAPSULATION_MODE' attribute in the phase 2 > 'TRANSFORM'. Sometimes this gets set to a value incompatible with other > equipment ( cisco ). > > Can someone please point me to where I can find more information on this > matter. Has anything changed in openBSD with regard to this, will openBSD > follow RFC3947 with regard to the encapsulation modes ( or is RFC3947 deas, it > seems to be a standard proposal since 2005 ). > > Mit freundlichen Gr��en > > Christoph Leser > > S&P Computersysteme GmbH > Zettachring 4 > 70567 Stuttgart Fasanenhof > > EMail: le...@sup-logistik.de > > You misunderstand. OpenBSD uses the proper assigned encapsulation mode values from the newer internet-drafts and the published RFC: http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-04#section-5.1 http://tools.ietf.org/html/rfc3947#section-5.1 It is Cisco who use the old encapsulation mode values from the early versions of the internet-draft (marked "XXX CHANGE" here): http://tools.ietf.org/html/draft-ietf-ipsec-nat-t-ike-03#section-5.1
Re: A suggestion for snapshots
On Fri, Sep 06, 2013 at 01:19:02PM -0700, Bryan Vyhmeister wrote: > On Fri, Sep 06, 2013 at 06:59:29PM +0200, Marc Espie wrote: > > There are also bottlenecks in fanning out from the actual build machines. > > Ports bulk builders are aware of the issues. These take time to solve. > > Would additional fast build machines help? Is that a large part of the > problem? > > Bryan Nope, I think that network bandwidth and topology is part of the current problem, and lack of time from some of the people involved to fix it.
Re: A suggestion for snapshots
On Fri, Sep 06, 2013 at 06:59:29PM +0200, Marc Espie wrote: > There are also bottlenecks in fanning out from the actual build machines. > Ports bulk builders are aware of the issues. These take time to solve. Would additional fast build machines help? Is that a large part of the problem? Bryan
Re: A suggestion for snapshots
On Fri, Sep 06, 2013 at 03:14:44PM +0300, Lars Engblom wrote: > For example in this moment, as I write this, Firefox can not be > installed in a new system installed from snapshots, as the packages > are compiled against an older snapshot (amd64) Known issue. > If there are just space on the ftp servers, I would suggest keeping > two snapshots: That's the problem. Requiring that would put a lot of mirrors out of the game. There are also bottlenecks in fanning out from the actual build machines. Ports bulk builders are aware of the issues. These take time to solve.
ISAKMPD NAT/Traversal
Hello, list, from a remark by Stuart Henderson on an older thread http://marc.info/?l=openbsd-misc&m=134849 788026722&w=2 back in September 2012,I understood that NAT-T support in openBSD was not complete at that time, especially the handling of the 'ENCAPSULATION_MODE' attribute in the phase 2 'TRANSFORM'. Sometimes this gets set to a value incompatible with other equipment ( cisco ). Can someone please point me to where I can find more information on this matter. Has anything changed in openBSD with regard to this, will openBSD follow RFC3947 with regard to the encapsulation modes ( or is RFC3947 deas, it seems to be a standard proposal since 2005 ). Mit freundlichen Grüßen Christoph Leser S&P Computersysteme GmbH Zettachring 4 70567 Stuttgart Fasanenhof EMail: le...@sup-logistik.de
A suggestion for snapshots
Quite often the snapshot of the packages and the base system are out of sync, because naturally, the base has to be built before packages. For example in this moment, as I write this, Firefox can not be installed in a new system installed from snapshots, as the packages are compiled against an older snapshot (amd64) If there are just space on the ftp servers, I would suggest keeping two snapshots: one complete with both base and packages (always in sync) and one with just the newest base. This would make life easier for people following snapshots. Regards, Lasse
Re: laptop PS2 External Mouse in X
On Sep 06 09:23:56, riccardo.mott...@libero.it wrote: > >an apparently trivial question. On my ThinkPad 600x, I can only > >use the internal track-point with X11. If I attach an external > >PS/2 mouse, it does not get used. I don't have xorg.conf, I am > >accustomed that with other OS's it "just works". I also tried > >plugging it in earlier, even at boot time. The light of the > >optical mouse works, thus it gets powered up. > > let me clarify. If I stick in the external mouse at boot time, it > will be recognized and only the external mouse will work (it > actually stopped working with a some error messages I will report > below) and the internal trackpoint si inactive, even if i remove the > external mouse. > If I start with no mouse, the internal trackpoint works, but not the > external mouse. This is how it's supposed to work, right? http://en.wikipedia.org/wiki/PS/2_connector#Hotplugging > With both setups, dmesg spits out the same: > pms0 at pckbc0 (aux slot) > pckbc0: using irq 12 for aux slot > wsmouse0 at pms0 mux 0 Looks fine. > > I'm accustomed from other OS's (not just windows, but also Linux, > FreeBSD.. I will check NetBSD) that I can just plug-in/plug-out an > external mouse, You mean, these OSes on this very same laptop? With this mouse (not an USB mouse)? > This is very convenient in laptop usage. I know it > doesn't work with desktops, but with laptops yes. It's not a matter of a "desktop" vs a "laptop". > Or could this be a limitation not of the OS but of this particular laptop? Try the other OSes where it "works" on this laptop with this mouse and find out. > On a forum I found this (referred to a guy tryin gto attach a > keyboard and not a mouse) > > "The problem is that the port on the 600 series is a mouse port and > not internally wired as a true PS2 port. Could you please describe the difference bwtween a "mouse port" and a "true PS2 port"? > You can overcome the problem by either using a PS2 splitter or a USB > keyboard." > Is this bogus or could this be a problem? USB mouses and keyboards you sholud be able to plug in and out as you wish.
Re: laptop PS2 External Mouse in X
Hi, Riccardo Mottola wrote: Hi, an apparently trivial question. On my ThinkPad 600x, I can only use the internal track-point with X11. If I attach an external PS/2 mouse, it does not get used. I don't have xorg.conf, I am accustomed that with other OS's it "just works". I also tried plugging it in earlier, even at boot time. The light of the optical mouse works, thus it gets powered up. let me clarify. If I stick in the external mouse at boot time, it will be recognized and only the external mouse will work (it actually stopped working with a some error messages I will report below) and the internal trackpoint si inactive, even if i remove the external mouse. If I start with no mouse, the internal trackpoint works, but not the external mouse. With both setups, dmesg spits out the same: pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 I'm accustomed from other OS's (not just windows, but also Linux, FreeBSD.. I will check NetBSD) that I can just plug-in/plug-out an external mouse, This is very convenient in laptop usage. I know it doesn't work with desktops, but with laptops yes. Or could this be a limitation not of the OS but of this particular laptop? On a forum I found this (referred to a guy tryin gto attach a keyboard and not a mouse) "The problem is that the port on the 600 series is a mouse port and not internally wired as a true PS2 port. You can overcome the problem by either using a PS2 splitter or a USB keyboard." Is this bogus or could this be a problem? Riccardo
