Re: mailx : mime handling?
Predrag Punosevac punoseva...@gmail.com wrote: On 2013-09-26 Thu 10:15 AM |, Roberto E. Vargas Caballero wrote: I use mutt basically because it has threading support, and I cannot live without it. NetBSD version of mailx does support threading as well http://netbsd.gw.com/cgi-bin/man-cgi?mailx++NetBSD-current and it does have the right license :) Cheers, Predrag Heirloom mailx also supports threads and has BSD license. Who wants such an mailx, can install the port. If you make from OpenBSD mailx a mailx similar to heirloom mailx, then there will be no small mail client anymore. Perhaps the only interesting improvement of mailx would be to make it possible to pass the headers through an external filter: for searching, ordering, etc. As far as I know this is not possible. Heirlom mailx has also an interesting -H option. For supporting mime, perhaps can everyone write his own script. For example tcl tcl using tcllib, there is a library for Manipulation of MIME body parts. BTW, I just discovered that also alpine supports threading. I never used it. Rodrigo.
Re: how to compare ipsec.conf and isakmpd.conf settings?
Original message from Stuart Henderson at 26-9-2013 23:58 On 2013-09-26, Daniel Polak dan...@sys.nl wrote: I'd like to see how isakmpd interprets the settings in ipsec.conf and isakmpd.conf and would like to compare those interpretations. ipsecctl -nvf /etc/ipsec.conf shows the settings from ipsec.conf as they would be used by isakmpd but don't see how to do the same with isakmpd.conf. How can I get the settings from isakmpd.conf and ipsec.conf in the same format so I can compare them? isakmpd does not interpret settings in ipsec.conf *at all*; ipsecctl converts them into control commands which generate isakmpd.conf sections. to compare, you'll need to adjust the format manually; ipsecctl -nvf outputs a bunch of lines like this: C set [sectionname]:variable1=setting1 C set [sectionname]:variable2=setting2 C set [sectionname]:variable3=setting3 which equate to isakmpd.conf entries like this: [sectionname] variable1=setting1 variable2=setting2 variable3=setting3 Writing how isakmpd interprets the settings in ipsec.conf was slightly misleading, sorry about that. I do understand that ipsecctl reads ipsec.conf, generates control commands and thereby sets up isakmpd. I have now solved my immediate problem and things are working (I overlooked that the connection was set for passive mode in ipsec.conf and for active mode in isakmpd, and the connection only worked when the my side initiated it). What would have helped me solve this is a way to see what the current configuration of isakmpd looks like (irrespective of whether it was loaded from isakmpd.conf or from ipsec.conf). It appears there is no equivalent of a C get all command to the FIFO to get the configuration values of all sections in the running isakmpd configuration. In spite of having used isakmpd for many years I still don't find troubleshooting VPN issues easy :-( Daniel
Re: how to compare ipsec.conf and isakmpd.conf settings?
On 9/27/13 10:46 AM, Daniel Polak wrote: What would have helped me solve this is a way to see what the current configuration of isakmpd looks like (irrespective of whether it was loaded from isakmpd.conf or from ipsec.conf). It appears there is no equivalent of a C get all command to the FIFO to get the configuration values of all sections in the running isakmpd configuration. If you send isakmpd a SIGUSR1, it will generate /var/run/isakmpd.report which also has the running configuration in it.
Block with reply-to
Fellow users, do I understand correctly that RST replies to packets blocked with pf cannot be arbitrarily routed? pf.conf(5) says that (...) reply-to is useful only in rules that create state. Since 'block' and 'match' rules seem to (understandably) not create state entries, there is no apparent way to direct TCP-RST (and/or ICMP unreachable) replies to a route of traffic being blocked. In my environment they all go through default gateway. Is there something that I'm missing or is it a bug or a feature (should I use route(8) tables instead, perhaps)? Thanks,
Freescale i.MX 6
Hi! There was a mention of this platform earlier, but is this platform usable yet? I'm getting myself a Utilite, and was hoping I could use OpenBSD in it. This is ARM, but as far as I understood the platform is beagle, am I right? -- chs,
Re: Freescale i.MX 6
Christer Solskogen christer.solskogen at gmail.com writes: There was a mention of this platform earlier, but is this platform usable yet? I'm getting myself a Utilite, and was hoping I could use OpenBSD in it. This is ARM, but as far as I understood the platform is beagle, am I right? http://marc.info/?l=openbsd-cvsm=137850037603645w=2
Re: Freescale i.MX 6
Hey, I have added support for the i.MX6 SoC to the tree. The platform is now called armv7 instead of beagle. There might be some changes needed to support the Utilite, too. Apart from that it should be usable. \Patrick Am 27.09.2013 um 13:04 schrieb Christer Solskogen christer.solsko...@gmail.com: Hi! There was a mention of this platform earlier, but is this platform usable yet? I'm getting myself a Utilite, and was hoping I could use OpenBSD in it. This is ARM, but as far as I understood the platform is beagle, am I right? -- chs,
Re: Freescale i.MX 6
On Fri, Sep 27, 2013 at 6:04 AM, Christer Solskogen christer.solsko...@gmail.com wrote: Hi! There was a mention of this platform earlier, but is this platform usable yet? I'm getting myself a Utilite, and was hoping I could use OpenBSD in it. This is ARM, but as far as I understood the platform is beagle, am I right? -- chs, Another alternative is http://cubox-i.com/ These are all i.MX6, the high end model is $120.
Re: mailx : mime handling?
hru...@gmail.com wrote: Predrag Punosevac punoseva...@gmail.com wrote: On 2013-09-26 Thu 10:15 AM |, Roberto E. Vargas Caballero wrote: I use mutt basically because it has threading support, and I cannot live without it. NetBSD version of mailx does support threading as well http://netbsd.gw.com/cgi-bin/man-cgi?mailx++NetBSD-current and it does have the right license :) Cheers, Predrag Heirloom mailx also supports threads and has BSD license. Who wants such an mailx, can install the port. If you make from OpenBSD mailx a mailx similar to heirloom mailx, then there will be no small mail client anymore. I would suggest that you compare man pages for Heirloom mailx and NetBSD version of mailx. Heirloom mailx does so much more than attachments and threading. It is still the smallest fully featured MUA in existance. To be frank with you I was checking your claim about Heriloom license. Makefile has indeed this line #BSD I would sware that it was custom license but you might be actually right on that one. I was wondering if William Yodlowsky can confirm licensing. Perhaps the only interesting improvement of mailx would be to make it possible to pass the headers through an external filter: for searching, ordering, etc. As far as I know this is not possible. Heirlom mailx has also an interesting -H option. There are bunch of interesting ideas from NMH that could really add to the original mailx but then it would not be original mailx. NMH is the only MUA besides original mailx that never stops to impress me. Predrag For supporting mime, perhaps can everyone write his own script. For example tcl tcl using tcllib, there is a library for Manipulation of MIME body parts. BTW, I just discovered that also alpine supports threading. I never used it. Rodrigo.
Re: Freescale i.MX 6
On Fri, Sep 27, 2013 at 1:31 PM, Patrick Wildt m...@patrick-wildt.de wrote: Hey, I have added support for the i.MX6 SoC to the tree. The platform is now called armv7 instead of beagle. There might be some changes needed to support the Utilite, too. Apart from that it should be usable. Okay, which image / kernel can I use to test this? I ordered mine today, so it will take at least six weeks before it gets here. Also, if you want one, order it and I'll send you money for it. -- chs
Snapshots of Sep 24
Hello! I was updating my amd64 laptop with September 24 snapshot's bsd.rd, and it didn't let me select etc and xetc sets - they were simply missing in the list of sets. Is it a glitch? Or may be I missed some news? -- Dmitrij D. Czarkoff
Re: Freescale i.MX 6
Thanks to Christer I have just placed an order for an Utilite, too. :) Thank you very much! \Patrick Am 27.09.2013 um 21:54 schrieb Christer Solskogen christer.solsko...@gmail.com: On Fri, Sep 27, 2013 at 1:31 PM, Patrick Wildt m...@patrick-wildt.de wrote: Hey, I have added support for the i.MX6 SoC to the tree. The platform is now called armv7 instead of beagle. There might be some changes needed to support the Utilite, too. Apart from that it should be usable. Okay, which image / kernel can I use to test this? I ordered mine today, so it will take at least six weeks before it gets here. Also, if you want one, order it and I'll send you money for it. -- chs
Re: Freescale i.MX 6
On Fri, Sep 27, 2013 at 11:46 PM, Patrick Wildt m...@patrick-wildt.de wrote: Thanks to Christer I have just placed an order for an Utilite, too. :) Thank you very much! My pleasure. Now we just need to wait six weeks :) -- chs,
Re: Snapshots of Sep 24
On 09/27/13 21:44, Dmitrij D. Czarkoff wrote: Hello! I was updating my amd64 laptop with September 24 snapshot's bsd.rd, and it didn't let me select etc and xetc sets - they were simply missing in the list of sets. Is it a glitch? Or may be I missed some news? Install allows the selection of etc / xetc. Upgrade does not give those as an option. parts of etc / xetc are updated using sysmerge. You might have changed the configuration, you don't want to lose those changes. See FAQ 4.5.1 , Upgrade: Install a new set of install files on this machine, but do not overwrite any configuration information, user data, or additional programs. No disk formatting is done, nor are the /etc or /var directories overwritten. A few important notes: See FAQ 4.7 .. The etc53.tgz and xetc53.tgz sets are not installed as part of an upgrade, only as part of a complete install, so any customizations you make will not be lost. You will have to update your /etc, /dev and /var directories manually. It's been this way for a long time.
