netfwd

2007-10-22 Thread Alexey Vatchenko

Hi!

I did a port of netfwd (http://www.bsdua.org/netfwd.html) See 
http://undeadly.org/cgi?action=articlesid=2007101823


The port is here: http://www.bsdua.org/files/tmp/netfwd-port.tar.gz

It's my first port, so be kind :)

Please cc: me, i'm not subscribed to the list.
Thanks!

--
Alexey Vatchenko
http://www.bsdua.org
E-mail: [EMAIL PROTECTED]
JID: [EMAIL PROTECTED]



Re: NEW:TclX 8.4

2007-10-22 Thread Valery Masiutsin
 Hi!

 It doesn't package correctly if /usr/local/lib/tclx8.4/libtclx84.so.1.0
 is not in system. Missing WANTLIB in Makefile and redundant RUN_DEPENDS
 variables + it could be done without automake/autoconf.

 Maybe you could take a look on tclx port I submitted to ports@
 some time ago:
 http://secure.lv/~nikns/stuff/ports/tclx-8.4.tar

 I am interested in having tclx in tree too.

Hello Nikns !

Thanks for the points with WANTLIB and RUN_DEPENDS, but i cant agree
with your point about automake/autoconf.
I think that direct patching of generated configure scripts is an
extremely questionable thing, especially when you have access to
original *.ac/*.m4 files, and can patch source of the problem and
generate proper configure script. AFAIK openbsd ports intended for
package building and not for installing of software (well in most
cases), so i see no problem in usage of autoconf/automake stuff for
package building.
libtclx84.so.X.X  is not in the ldconfig cache, it is loaded when you
loading tclx package with 'package require Tclx' in your script, but
it is a shared library nonetheless. Should we or not track it with
SHARED_LIBS ? I am not sure, probably should. But i think somebody of
more experienced folks can correct/enlighten me.
I think we should merge efforts with tclx port,to get it into the tree :)
Regards Valery



job proposal

2007-10-22 Thread Travelex Canada
Travelex Canada Limited 

Are you currently looking for an opportunity to work from home or
direct from your computer? Travelex Canada Limited wants to hear from
youThis is an sensational opportunity for you to work with Travelex
Canada Limited.

Travelex is the world’s largest non-bank commercial international payment
business and retail network with three head offices in Ontario - Canada,
UK and New York USA.

This is a fantastic opportunity to build an extremely rewarding career
and these opportunities would suit people who need flexible working
arrangements and Located anywhere in Canada, UK and USA. We have got
several opportunities available for Call Centre Service Representatives
and Support functions with a negotiable good salary starting from
$15,000.00 - $65,000.00 monthly.

Call Centre Service Representatives – Individuals in this role will be
outgoing, friendly and possess a high level of energy to support a fast
paced call center environment.

Support functions – These roles will include Finance, Human Resources,
Information Technology, Compliance, Legal, Risk  Compliance and
Operations.

The successful candidate will need to have customer service experience
and a computer with internet connnetion. Also you need to like working in
a team environment and have good communication skills.

**No prior experience required
**Work from home --- No daily commute!
**Spend more time with your family!
**Computer at home !

If you are interested in applying for potential openings with our
organization. You can fill the application form below :

 - FULL NAME:
 - ADDRESS:
 - CITY:
 - STATE:
 - COUNTRY:
 - TEL NUMBERS:
 - FAX NUMBERS:
 - Mobile NUMBERS:
 - COMPANY NAME(if any):
 - AGE:
 - STATUS(MARRIED/SINGLE):
 - Direct Mobile Number:
 - Forward your cover letter and resume attached .

PLEASE SUMMIT THE DETAILS WITH YOUR COVER LETTER AND RESUME DIRECTLY TO
THIS E-MAIL ADDRESS: [EMAIL PROTECTED]

Travelex Canada
website: http://www.travelex.ca/
Copyright 2007 Travelex Canada Limited


Problem with sysutils/tentakel on -current

2007-10-22 Thread Tasmanian Devil
Hello, list!

tentakel-2.1.2p1 installed from snapshots/packages/i386, which uses
python-2.5.1p4, seems to have a problem:

Traceback (most recent call last):
  File /usr/local/bin/tentakel, line 94, in module
conf.load(configfile)
  File 
/usr/obj/i386/tentakel-2.1.2p1/fake-i386/usr/local/lib/python2.5/site-packages/lekatnet/config.py,
line 163, in load
  File 
/usr/obj/i386/tentakel-2.1.2p1/fake-i386/usr/local/lib/python2.5/site-packages/lekatnet/config.py,
line 155, in parse
  File 
/usr/obj/i386/tentakel-2.1.2p1/fake-i386/usr/local/lib/python2.5/site-packages/lekatnet/tpg.py,
line 921, in __call__
  File 
/usr/obj/i386/tentakel-2.1.2p1/fake-i386/usr/local/lib/python2.5/site-packages/lekatnet/tpg.py,
line 934, in parse
  File string, line 8, in START
  File string, line 5, in SETTING
  File string, line 15, in PARAM
  File 
/usr/obj/i386/tentakel-2.1.2p1/fake-i386/usr/local/lib/python2.5/site-packages/lekatnet/tpg.py,
line 986, in extract
TypeError: object cannot be interpreted as an index

I don't know anything about Python, so I tried to reinstall both
tentakel and python, didn't help though.

On the same system (after deinstalling tentakel-2.1.2p1)
tentakel-2.1.2p0 installed from 4.1/packages/i386, which uses
python-2.4.4p5, works still fine.

Maybe I made some mistake, but it seems to me that there's an error in
the tentakel-2.1.2p1 package. Just wanted to let you know. Because of
the problem I use tentakel-2.1.2p0 so far.

Tas.



Re: NEW:TclX 8.4

2007-10-22 Thread Nikns Siankin
On Mon, Oct 22, 2007 at 10:52:44AM +0300, Valery Masiutsin wrote:
 Hi!

 It doesn't package correctly if /usr/local/lib/tclx8.4/libtclx84.so.1.0
 is not in system. Missing WANTLIB in Makefile and redundant RUN_DEPENDS
 variables + it could be done without automake/autoconf.

 Maybe you could take a look on tclx port I submitted to ports@
 some time ago:
 http://secure.lv/~nikns/stuff/ports/tclx-8.4.tar

 I am interested in having tclx in tree too.

Hello Nikns !

Thanks for the points with WANTLIB and RUN_DEPENDS, but i cant agree
with your point about automake/autoconf.
I think that direct patching of generated configure scripts is an
extremely questionable thing, especially when you have access to
original *.ac/*.m4 files, and can patch source of the problem and
generate proper configure script. AFAIK openbsd ports intended for
package building and not for installing of software (well in most
cases), so i see no problem in usage of autoconf/automake stuff for
package building.

Could anyone of ports commiters take a look on these tclx ports, please?


libtclx84.so.X.X  is not in the ldconfig cache, it is loaded when you
loading tclx package with 'package require Tclx' in your script, but
it is a shared library nonetheless. Should we or not track it with
SHARED_LIBS ? I am not sure, probably should. But i think somebody of
more experienced folks can correct/enlighten me.
I think we should merge efforts with tclx port,to get it into the tree :)
Regards Valery




Re: Maintainer Update: net/pptp

2007-10-22 Thread Christian Weisgerber
Stefan Sperling [EMAIL PROTECTED] wrote:

 This patch has been sitting on the list for a month now.
 Can someone please commit this?

Theo has requested that pptp should not set net.inet.gre.allow=1
when the package is installed, but only when the program is run,
i.e., add corresponding sysctl(3) calls to pptp proper.

* Add patch to ${WRKSRC}/util.c that prevents pptp
  from logging the same stuff into both /var/log/daemon
  and /var/log/messages. Just log to /var/log/daemon.

That doesn't sound right.  This is a syslog configuration issue.

-- 
Christian naddy Weisgerber  [EMAIL PROTECTED]



Re: Maintainer Update: net/pptp

2007-10-22 Thread Theo de Raadt
 Stefan Sperling [EMAIL PROTECTED] wrote:
 
  This patch has been sitting on the list for a month now.
  Can someone please commit this?
 
 Theo has requested that pptp should not set net.inet.gre.allow=1
 when the package is installed, but only when the program is run,
 i.e., add corresponding sysctl(3) calls to pptp proper.

This same idea should apply to other packages.

When you install a package on a machine, it should not open a gaping
hole in the machine.

Once you configure it, or run it, then it can do what it needs.

But doing a pkg_add *.tgz should not generate a less secure configuration
of a machine.  That is just clearly wrong.



jabberd ports Makefile patch

2007-10-22 Thread Alexander Iliev

Hi there.

I've contacted the ex-maintainer of this port (Gerardo Santana),
who directed me to this list, so I'm sending this patch here.
If anyone thinks that it's worth committing it into the tree -
go ahead. :)

The goal of the patch is to allow users to add extra configure
parameters during the build with:

make CONFIGURE_ARGS+=argument ...

Currently in the stable and current branches the Makefile does
not allow this (as far as could see).

Best regards,
--
Alexander Iliev
--- Makefile.orig   Sat Nov 11 16:38:23 2006
+++ MakefileMon Oct 22 17:25:39 2007
@@ -33,7 +33,7 @@
 FLAVOR?=   mysql
 
 CONFIGURE_STYLE=   gnu
-CONFIGURE_ARGS=--localstatedir=/var \
+CONFIGURE_ARGS+=   --localstatedir=/var \
--enable-ssl \
--disable-idn \
--with-extra-include-path=${EXTRA_INCLUDE_PATH} \




Re: UPDATE: security/gnutls

2007-10-22 Thread Landry Breuil
On 10/6/07, Giovanni Bechis [EMAIL PROTECTED] wrote:
 On Fri, Oct 05, 2007 at 09:07:02PM +0200, Landry Breuil wrote:
  Just a small notice.. apparently, your two diffs don't remove
  gnutls/patches/patch-{lib_Makefile_am,lib_Makefile_in,libextra_Makefile_am,libextra_Makefile_in
src_Makefile_in,src_retcodes_c} and
  opencdk/patches/patch-{src_Makefile_in,src_encrypt_c,src_keyserver_c,src_main_c
 ,src_misc_c,tests_t-stream_c}, and it doesn't compile with
  these patches still present.. maybe you've forgotten to cvs remove
  them ? And diff for gnutls needs to be updated, Makefile is at rev
  1.13 now.
 
 Thanks, I fixed that

From tests i've run, latest liferea seems happy with this gnutls
update, it would be kind if prelude and wmbiff users could try to
build these ports against this new gnutls version.

Landry



Re: jabberd ports Makefile patch

2007-10-22 Thread Ingo Schwarze
Hi Alexander,

Alexander Iliev wrote on Mon, Oct 22, 2007 at 07:50:02PM +0300:

 I've contacted the ex-maintainer of this port (Gerardo Santana),
 who directed me to this list, so I'm sending this patch here.

Gerardo requested being removed as MAINTAINER long ago:
  http://marc.info/?l=openbsd-portsm=116814655916274

 If anyone thinks that it's worth committing it into the tree -
 go ahead. :)

Your patch looks reasonable to me (but i could be wrong, i'm not
that experienced with ports).

But you should be aware that the net/jabberd port is *way*
out of date.  The version we have in tree suffers from
memory leaks, see my previous posts on the subject, and also
what merdely@ wrote on it.

When the version we have in tree was up to date, the jabberd2 project
was mostly dead.  In the meantime, Tomasz Sterna picked up the project
and is actively maintaining and improving it.

The current version is 2.1.18, the new homepage is
  http://jabberd2.xiaoka.com/

When i last tried porting jabberd2.1 (around 2.1.0 times)
i did not succeed.  I stumbled on weird linking issues, and
Tomasz was unresponsive back then.  Currently, Tomasz does
react quickly to inquiries, but now i do not find the time
to have another look.  So, i cannot judge 2.1.18 code quality,
but i *guess* it might be worth a look.

Thus, if you like, just give it a try yourself...

Yours,
  Ingo

--
Ingo Schwarze [EMAIL PROTECTED]
Serverbetrieb usta.de / studis.de



Re: Maintainer Update: net/pptp

2007-10-22 Thread Stefan Sperling
On Mon, Oct 22, 2007 at 04:51:25PM +, Christian Weisgerber wrote:
 Stefan Sperling [EMAIL PROTECTED] wrote:
 
  This patch has been sitting on the list for a month now.
  Can someone please commit this?
 
 Theo has requested that pptp should not set net.inet.gre.allow=1
 when the package is installed,

I hate to shift the blame, but sturm@ wanted me to add this
a while back. Originally the port didn't do this.

The argument back then was that things should work out of
the box once someone installs the port/package.

But I think the security argument has more weight,
so I'll gladly revert that change.

 but only when the program is run,
 i.e., add corresponding sysctl(3) calls to pptp proper.

Sure, I could add that to pptp itself.

But if we don't want to allow 'pkg_add pptp' to enable
an insecure protocol, why do we want to allow executing
pptp to do so?

Isn't the idea to have the user _manually_ turn a knob
if that knob makes the system more insecure?

 * Add patch to ${WRKSRC}/util.c that prevents pptp
   from logging the same stuff into both /var/log/daemon
   and /var/log/messages. Just log to /var/log/daemon.
 
 That doesn't sound right.  This is a syslog configuration issue.

I don't know, but I don't think so.
I'm using the default syslog config. Never touched it:

  [~] $ grep -v '^#' /etc/syslog.conf 
  
  *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages
  kern.debug;syslog,user.info /var/log/messages
  auth.info   /var/log/authlog
  authpriv.debug  /var/log/secure
  cron.info   /var/cron/log
  daemon.info /var/log/daemon
  ftp.info/var/log/xferlog
  lpr.debug   /var/log/lpd-errs
  mail.info   /var/log/maillog
  
  
  
  *.emerg *
 

The problem as I see it is this:

pptp is using LOG_NOTICE to log 'normal' messages.
For some reason unknown to me these messages end up in two
different log files (daemon and messages), which is really,
really annoying when trying to figure out a failed connection
attempt with tail -f.

ppp(8) does not spam the syslog the way pptp(8) does without the patch.
ppp(8) never uses LOG_NOTICE at all, it uses LOG_INFO instead.

So the patch makes pptp use LOG_INFO for normal messages, too,
which settles the issue for me.

Do you know a better solution?

Extract from pptp/util.c without patch:

  /*** print a message to syslog 
/
  void _log(const char *func, const char *file, int line, const char *format, 
...)
  {
  MAKE_STRING(log);
  syslog(LOG_NOTICE, %s, string);
  }
  

Extract from /usr/src/usr.sbin/ppp/ppp/log.c,
note the absence of LOG_NOTICE:

  static int
  syslogLevel(int lev)
  {
switch (lev) {
case LogLOG:
  return LOG_INFO;
case LogDEBUG:
case LogTIMER:
  return LOG_DEBUG;
case LogWARN:
  return LOG_WARNING;
case LogERROR:
  return LOG_ERR;
case LogALERT:
  return LOG_ALERT;
}
return lev = LogMIN  lev = LogMAX ? LOG_INFO : 0;
  }


-- 
stefan
http://stsp.name PGP Key: 0xF59D25F0


pgpw85XY0U07z.pgp
Description: PGP signature


Re: Maintainer Update: net/pptp

2007-10-22 Thread Theo de Raadt
 But if we don't want to allow 'pkg_add pptp' to enable
 an insecure protocol, why do we want to allow executing
 pptp to do so?
 
 Isn't the idea to have the user _manually_ turn a knob
 if that knob makes the system more insecure?

This is rather simple to break apart.

installing a package does not mean you are going to use it.

adding another knob that people don't know on another system
makes it more difficult to use openbsd.

there is an obvious middle ground.  starting an application
means you want to use it, so THAT is the moment when the permission
should be changed.

it is not like it is securelevel locked or some such thing.



Re: Maintainer Update: net/pptp

2007-10-22 Thread Stefan Sperling
On Mon, Oct 22, 2007 at 03:03:51PM -0600, Theo de Raadt wrote:
  But if we don't want to allow 'pkg_add pptp' to enable
  an insecure protocol, why do we want to allow executing
  pptp to do so?
  
  Isn't the idea to have the user _manually_ turn a knob
  if that knob makes the system more insecure?
 
 This is rather simple to break apart.
 
 installing a package does not mean you are going to use it.
 
 adding another knob that people don't know on another system
 makes it more difficult to use openbsd.

OK, we go for middle ground then.

Updated diff and updated list of changes.

List of changes:

  * Update my email address.
  * Add detailed option descriptions to pptp(8) man page.
  * Move OpenBSD configuration examples from text file
${PREFIX}/share/doc/pptp/USING into pptp(8) man page,
and remove patch to ${WRKSRC}/USING. Extend and
revise examples while at it.
  * Add patch to ${WRKSRC}/util.c to make pptp log with
level LOG_INFO by default instead of LOG_NOTICE.
This prevents pptp from logging the same messages into
both /var/log/daemon and /var/log/messages, which is
really annoying if trying to figure out failing connection
attempts by running tail -f on those log files.
  * Update pkg/DESCR with a new description based on
upstream web site.
  * Fix URL to list of pptp security flaws in pkg/MESSAGE.
  * [Re-]Create patches with `make update-patches'.
  * Add patch to ${WRKSRC}/pptp_gre.c to automatically enable
the net.inet.gre.allow sysctl before trying to bind
the GRE socket, and disable the sysctl again after
closing the socket.
  * Remove '@sysctl net.inet.gre.allow=1' from PLIST.

Index: Makefile
===
RCS file: /cvs/ports/net/pptp/Makefile,v
retrieving revision 1.17
diff -u -r1.17 Makefile
--- Makefile15 Sep 2007 22:36:58 -  1.17
+++ Makefile22 Oct 2007 21:52:34 -
@@ -3,13 +3,15 @@
 
 COMMENT=   PPTP client package for Microsoft VPN servers
 
-DISTNAME=  pptp-1.7.1
+VERSION=   1.7.1
+DISTNAME=  pptp-${VERSION}
+PKGNAME=   ${DISTNAME}p0
 CATEGORIES=net
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=pptpclient/}
 
 HOMEPAGE=  http://pptpclient.sf.net
 
-MAINTAINER=Stefan Sperling [EMAIL PROTECTED]
+MAINTAINER=Stefan Sperling [EMAIL PROTECTED]
 
 # GPL
 PERMIT_PACKAGE_CDROM=   Yes
Index: files/pptp_8
===
RCS file: /cvs/ports/net/pptp/files/pptp_8,v
retrieving revision 1.5
diff -u -r1.5 pptp_8
--- files/pptp_812 Nov 2006 10:10:09 -  1.5
+++ files/pptp_822 Oct 2007 21:52:34 -
@@ -14,10 +14,19 @@
 .Sh SYNOPSIS
 .Nm
 .Ar hostname
-[
-.Op Ar --phone phone number
-.Op Ar --quirks ISP_NAME
--- ]
+.Op Fl -version
+.Op Fl -phone Ar number
+.Op Fl -nolaunchpppd 
+.Op Fl -quirks Ar quirk
+.Op Fl -debug
+.Op Fl -sync
+.Op Fl -timeout Ar secs
+.Op Fl -nobuffer
+.Op Fl -idle-wait Ar time
+.Op Fl -max-echo-wait Ar time
+.Op Fl -logstring Ar name
+.Op Fl -localbind Ar addr
+.Op Fl -loglevel Ar level
 .Op Ar ppp options
 .Sh DESCRIPTION
 .Nm
@@ -37,33 +46,285 @@
 The
 .Ar hostname
 parameter specifies which host should be contacted as the PPTP server.
-Additional parameters are passed on to
-.Ic ppp
+.Pp
+.Op Ar ppp options
+are passed on to
+.Xr ppp 8
 and typically include a remote username or a file containing options.
 .Pp
 .Nm
 must be run as root.
-
-.Sh EXAMPLE
+.Pp
 .Nm
-.Ar hostname
-.Op Ar ppp options
+accepts the following options:
+.Bl -tag -width Ds
+.It Fl -version
+Display version number and exit.
+.It Fl -phone Ar number
+Pass
+.Ar number
+to remote host as phone number.
+.It Fl -nolaunchpppd 
+Do not launch a ppp daemon, for use as a ppp daemon pty.
+.It Fl -quirks Ar quirk
+Work around a buggy PPTP implementation.
+The only currently recognised value is
+.Ar BEZEQ_ISRAEL .
+See the file
+.Pa PREFIX/share/doc/pptp/USING
+for details.
+.It Fl -debug
+Run in foreground (for debugging with gdb).
+.It Fl -sync
+Enable Synchronous HDLC.
+.Xr ppp 8
+must use it, too.
+.It Fl -timeout Ar secs
+Time to wait for reordered packets (0.01 to 10 secs).
+.It Fl -nobuffer
+Disable packet buffering and reordering completely
+.It Fl -idle-wait Ar secs
+Time to wait before sending echo request.
+.It Fl -max-echo-wait Ar secs
+Time to wait before giving up on lack of reply. This option
+seems to be unimplemented, because the flag can be set but is
+never evaluated (look at pptp_ctrl.c) \(em dead, unused code?
+.It Fl -logstring Ar name
+Use
+.Ar name
+instead of
+.Dq anon
+in syslog messages.
+.It Fl -localbind Ar addr
+Bind to specified IP address instead of wildcard.
+.It Fl -loglevel Ar level
+Sets the debugging level (0=low, 1=default, 2=high).
+.Sh EXAMPLES
+.Ss PPTP on a stand-alone VPN client
+This example assumes that you want to use pptp to connect
+to a VPN and use the VPN connection as your default route.
+Let us assume that the VPN server was called 

Re: Maintainer Update: net/pptp

2007-10-22 Thread Paul de Weerd
On Tue, Oct 23, 2007 at 12:07:50AM +0200, Stefan Sperling wrote:
|   * Add patch to ${WRKSRC}/pptp_gre.c to automatically enable
| the net.inet.gre.allow sysctl before trying to bind
| the GRE socket, and disable the sysctl again after
| closing the socket.

Is disabling after use the best way to go ? Perhaps just check if it's
set before running and return that state at program end. This seems
the way of the least surprise to me. If you enable this willingly and
knowingly, it would be bad if pptp would disable it unconditionally at
program end.

Just my two rappen ;)

Cheers,

Paul 'WEiRD' de Weerd

-- 
[++-]+++.+++[---].+++[+
+++-].++[-]+.--.[-]
 http://www.weirdnet.nl/