Re: qmail under 8.0-STABLE
On Thu, 15 Jul 2010 23:40:33 -0600 Peter fb...@peterk.org wrote: I have the following config: FreeBSD ppert-zone.com 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Apr 14 01:44:13 UTC 2010 r...@canopus.ispsystem.net:/root/src/sys/i386/compile/ISPSYSTEM i386 it is a vps running via a jail. I have installed mail/qmail and added it to rc.conf. It starts just fine but no remote mail ever gets delivered/received. DNS wise the machine is pointed to a A record for it's domain but the provider has not (and will not) set up a reverse. Note: According to qmail-qstat/qmail-qread the mail is not in the queue either like it was before adding qmail startup to the rc.conf Ideas? What does the MX record for that domain point to? [dig mx domain.com] No MX Are you sure qmail is running/listening? [sockstat / netstat -an] Yes running Did you shutoff sendmail in rc.conf? sendmail_enable=NONE I think... No sendmail is not running ]Peter[ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
2010/7/16 Dan Nelson dnel...@allantgroup.com: In the last episode (Jul 16), Ashish SHUKLA said: Dan Nelson writes: In the last episode (Jul 15), Jens Rehsack said: Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The above output looks perfect, and should match the top three lines in /your etc/passwd files. Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. Was difficult for me to format the single liner ;) To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Could you please take a look to my other mail (getgrent related) - there seems another bug ... Try the following patch: Can I do this without a full world rebuild? (I do not develop in FBSD actively). Otherwise I recommend (the test case was in OP) that someone with a separate test box tries it out and commit it etc. I had to develop a workaround for all other boxes anyway. Thank you very much, Jens Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sata Tape Drives
Il 07/16/10 00:24, Dan Nelson ha scritto: In the last episode (Jul 15), Michael Anderson said: Or, more clearly: Are SATA tape drives supported? I see they are on some other BSD flavors, but I haven't found any mention in the FreeBSD hardware compatibility documents. I see an atapist device in /sys/conf/NOTES: device atapist # ATAPI tape drives , which might work. The atapicam or ahci device may also make sata tapes show up as if they were scsi devices. Try ahci first. http://www.freebsd.org/cgi/man.cgi?query=ahci http://www.freebsd.org/cgi/man.cgi?query=atapicam And please, in case you try, let us know the results... I know I'm not helping you, but I've tried many times to find out whether SATA *and SAS* tape drives are expected to work. bye Thanks av. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
kernel panics
Where is the best place to report problems with kernel panics in FreeBSD 8.0 and to get help? I posted a message in this mailing list freebsd-questions, but if acutally never was published (?) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: qmail under 8.0-STABLE
On Thu, 15 Jul 2010 23:40:33 -0600 Peter fb...@peterk.org wrote: I have the following config: FreeBSD ppert-zone.com 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Apr 14 01:44:13 UTC 2010 r...@canopus.ispsystem.net:/root/src/sys/i386/compile/ISPSYSTEM i386 it is a vps running via a jail. I have installed mail/qmail and added it to rc.conf. It starts just fine but no remote mail ever gets delivered/received. DNS wise the machine is pointed to a A record for it's domain but the provider has not (and will not) set up a reverse. Note: According to qmail-qstat/qmail-qread the mail is not in the queue either like it was before adding qmail startup to the rc.conf Ideas? What does the MX record for that domain point to? [dig mx domain.com] No MX You need an MX record for that domain. If using bind simplest way would be to: ie: for emails @domain.com domain.com. IN MX 1 mail.domain.com. as long as mail.domain.com resolves to the correct IP. If you want email for subdomains... ie:@qmail.domain.com mail.domain.com. IN MX 1 mail.domain.com. etc.etc. Are you sure qmail is running/listening? [sockstat / netstat -an] Yes running Did you shutoff sendmail in rc.conf? sendmail_enable=NONE I think... No sendmail is not running ]Peter[ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
cannot install opera
sudo portsnap fetch update cd /usr/ports/www/opera /usr/ports/www/operasudo make install clean Password: === opera-10.10.20091120_2 has known vulnerabilities: = opera -- Data URIs can be used to allow cross-site scripting. Reference: http://portaudit.FreeBSD.org/77b9f9bc-7fdf-11df-8a8d-0008743bf21a.html = Please update your ports tree and try again. *** Error code 1 Stop in /media/G/usr/ports/www/opera. does it mean the oepra vulnerabilities has not been fixed ? - e^(π⋅i) + 1 = 0 -- View this message in context: http://old.nabble.com/cannot-install-opera-tp29180746p29180746.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re : cannot install opera
Yesterday, I have written to the maintainer of the Opera port, and he gave me this link : http://www.freebsd.org/cgi/query-pr.cgi?pr=148294 The port update is in the pipes ;) Alexandre. --- En date de : Ven 16.7.10, zaxis z_a...@163.com a écrit : De: zaxis z_a...@163.com Objet: cannot install opera À: freebsd-questions@freebsd.org Date: Vendredi 16 juillet 2010, 7h14 sudo portsnap fetch update cd /usr/ports/www/opera /usr/ports/www/operasudo make install clean Password: === opera-10.10.20091120_2 has known vulnerabilities: = opera -- Data URIs can be used to allow cross-site scripting. Reference: http://portaudit.FreeBSD.org/77b9f9bc-7fdf-11df-8a8d-0008743bf21a.html = Please update your ports tree and try again. *** Error code 1 Stop in /media/G/usr/ports/www/opera. does it mean the oepra vulnerabilities has not been fixed ? - e^(π⋅i) + 1 = 0 -- View this message in context: http://old.nabble.com/cannot-install-opera-tp29180746p29180746.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: kernel panics
On Fri, Jul 16, 2010 at 9:03 AM, n dhert ndhert...@gmail.com wrote: Where is the best place to report problems with kernel panics in FreeBSD 8.0 and to get help? Have a look at http://www.freebsd.org/send-pr.html Cheers I posted a message in this mailing list freebsd-questions, but if acutally never was published (?) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: 2010/7/16 Dan Nelson dnel...@allantgroup.com: [...] Try the following patch: Thanks, I'll try it when I'm on my FreeBSD box. Can I do this without a full world rebuild? (I do not develop in FBSD actively). Otherwise I recommend (the test case was in OP) that someone with a separate test box tries it out and commit it etc. I don't think you need full world rebuild, just rebuilding world should do it. I had to develop a workaround for all other boxes anyway. As a workaround you can use setpwent(3). -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things.” (Robert A. Heinlein, 1973) pgpEMMcLPMPwi.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 08:36, Ashish SHUKLA wrote: Jens Rehsack writes: 2010/7/16 Dan Nelsondnel...@allantgroup.com: [...] Try the following patch: Thanks, I'll try it when I'm on my FreeBSD box. Great \o/ [...] I had to develop a workaround for all other boxes anyway. As a workaround you can use setpwent(3). I cached the entires - I rate setpwent as to dangerous. You can take a look at http://cpansearch.perl.org/src/REHSACK/DBD-Sys-0.01_01/lib/DBD/Sys/Plugin/Unix/Users.pm Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? You can take a look at http://cpansearch.perl.org/src/REHSACK/DBD-Sys-0.01_01/lib/DBD/Sys/Plugin/Unix/Users.pm Jens -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Q: Why UNIX geeks feel the need of a wife ? A: Since all UNIX geeks possess a large fortune db and according to Law of Jane Austen, It is a universal truth that a single man with a large fortune is in need of a wife.” (abbe, 2009) pgpuRlGdT7Don.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. , an excerpt from getpwent(3) | The setpassent() function accomplishes two purposes. First, it causes | getpwent() to ``rewind'' to the beginning of the database. Additionally, | if stayopen is non-zero, file descriptors are left open, significantly | speeding up subsequent accesses for all of the routines. (This latter | functionality is unnecessary for getpwent() as it does not close its file | descriptors by default.) | | It is dangerous for long-running programs to keep the file descriptors | open as the database will become out of date if it is updated while the | program is running. | | The setpwent() function is identical to setpassent() with an argument of | zero. ` I can't see anything which says about modifying NSS database. AFAIK none of the NSS routines allow you to write on database, you've to use the database specific method to modify the database. HTH -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Age is not an accomplishment, and youth is not a sin.” (Robert A. Heinlein, Methuselah's Children, 1958) pgpwVZo684yN8.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 09:59, Ashish SHUKLA wrote: Jens Rehsack writes: On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. , an excerpt from getpwent(3) [...] ` I can't see anything which says about modifying NSS database. AFAIK none of the NSS routines allow you to write on database, you've to use the database specific method to modify the database. You're absolutely right - I never took a deeper look, because I always was only interested to read the (user|group) data and expected setpwent to modify such an entry. A quick look into Stevens Advanced Programming in the UNIX environment could had enlighten myself. Sorry that I didn't RTFM carefully. Best regards and many, many thanks, Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: [...] You're absolutely right - I never took a deeper look, because I always was only interested to read the (user|group) data and expected setpwent to modify such an entry. Its UNIX :P A quick look into Stevens Advanced Programming in the UNIX environment could had enlighten myself. Sorry that I didn't RTFM carefully. No problems. -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Software and cathedrals are much the same - first we build them, then we pray.” (anonymous) pgp1S6yBF1i4t.pgp Description: PGP signature
Re: GUI for ACL
On Fri, 16 Jul 2010 09:17:25 +0530 Ashish SHUKLA ash...@freebsd.org articulated: I've not used KDE since they released KDE 4, but IIRC, KDE 3.5.x used to have ACL support integrated in it[1] by default. Are you sure there isn't any such setting you probably missing during compilation in KDE 4.x ? References: [1] http://www.flickr.com/photos/wahjava/507889368/#/ No really. You cannot add users or change individual user's permissions via KDE's default file browser. Obviously, I can accomplish most of what I want to do from the command line, abet more slowly and error prone. Having read up on a few Googled items, it appears that FreeBSD has not matured sufficiently yet to allow full integration of ACLs. Supposedly, 9.x will offer better integration. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ signature.asc Description: PGP signature
Sticky bit Change ??
Hello all, Thank you for your response in advance. I am running i386 FreeBSD 7.2 p4 on an HP DL380 G2. I upgraded from 6.1 p23 in March but the machine was built last fall. I am not at liberty to upgrade the machine due to its purpose. However I agree it is time. I had been using sticky bits set on directories to allow groups of users to upload files but making sure only the file or directory owner could modify the file. The directory owner would retrieve the file and delete it. It seems that my later release no longer allows the directory owner to manipulate (delete) the files. This functioned in the earlier release. The documentation sees to be at odds. The current Freebsd Handbook claims that only the file owner is allowed to manipulate a file loaded in the directory where the sticky bit is set. However, in the man pages, sticky(8) claims that root, the directory owner, and the file owner are allowed to manipulate (write/delete) the file. It appears that I have found a bug in documentation or code. Can you tell me where the issue is, code or documentation?If this is a conscious change by the project, can you suggest an alternate method to achieve the functionality? I apologize if I missed documentation that describes this as a change. Thank you, Ray ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
OT 8.1 Release Status
I noticed that the 8.1 release status page hasn't been updated since the 4th. I know the team is very close to the release. The last indication is that the geom system needs work. Can someone update the page? I hate to send Is it done yet? sorts of e-mails so I keep checking the release update page http://wiki.freebsd.org/Releng/8.1TODO , but there was supposed to be a release on the 9th and I thought it might be time to ask for the page to be updated... (Note: I do not want to push the team. I know as a developer I put more pressure on myself to finish things than others, and I hate the idea of a 'regular release schedule'. When things are ready, it will be released. Just wondering how things are going...) Mark Moellering ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 16), Jens Rehsack said: 2010/7/16 Dan Nelson dnel...@allantgroup.com: In the last episode (Jul 16), Ashish SHUKLA said: Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. Was difficult for me to format the single liner ;) To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Could you please take a look to my other mail (getgrent related) - there seems another bug ... Do you have another one-liner that will reproduce it? A simple /usr/bin/getent group doesn't return dupes for me. Oddly enough, the *grent code doesn't use an internal counter, so the bug you found in endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that easy to read). Try the following patch: Can I do this without a full world rebuild? (I do not develop in FBSD actively). Assuming your test programs are dynamically linked, you only need to rebuld libc. Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
2010/7/16 Dan Nelsondnel...@allantgroup.com:
In the last episode (Jul 16), Ashish SHUKLA said:
Well, OP is also invoking 'endpwent()' after every 'getpwent()'
invocation which according to GNU/Linux's glibc and NetBSD's libc (as
OP mentioned) should rewind the position in passwd database to the
beginning.
Ah. I missed the endpwent calls.
Was difficult for me to format the single liner ;)
To me it definitely looks like a bug in FreeBSD's getpw*() family of
functions.
As tested using sysutils/lsof, in the following program in FreeBSD, the
descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but
position in database is never rewinded as shown in the output.
It looks like the *pwent functions keep an internal counter that
endpwent doesn't reset.
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that easy
to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
Best regards,
Jens
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Xchess?
What ever happened to xchess the gnu-chess engine client? Did it merge into something else? Thanks, Chris Maness ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT 8.1 Release Status
On Fri, Jul 16, 2010 at 09:47:12AM -0400, Mark Moellering thus spake: I noticed that the 8.1 release status page hasn't been updated since the 4th. I know the team is very close to the release. The last indication is that the geom system needs work. Can someone update the page? I hate to send Is it done yet? sorts of e-mails so I keep checking the release update page http://wiki.freebsd.org/Releng/8.1TODO , but there was supposed to be a release on the 9th and I thought it might be time to ask for the page to be updated... (Note: I do not want to push the team. I know as a developer I put more pressure on myself to finish things than others, and I hate the idea of a 'regular release schedule'. When things are ready, it will be released. Just wondering how things are going...) Mark Moellering This is at the bottom of the release schedule. CAUTION: FreeBSD Release Schedules frequently slip -- the above release schedule should be interpreted with this caution in mind. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vs YouTube
in message 20100714192246.b4daa560.free...@edvax.de, wrote Polytropon thusly... On Wed, 14 Jul 2010 20:06:14 +0300, Odhiambo Washington odhia...@gmail.com wrote: Is this the same way the Linux users have it?:-) I don't think so. The Linux Flash plugin seems to work better on Linux than it does on FreeBSD. ... Flash stuff on Linux is to have this plugin installed for Firefox. As I'm not a regular Linux user, I can't be sure, but at least that's my opinion. :-) On CentOS 5.x, I have yet to experience a problem with videos on YouTube, Vimeo, some others while playing them in Firefox via Flash plugin. On FreeBSD, when possible, I download the file to play with xine. - parv -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 18:13, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
The dups I got are not duplicate:
$ less /var/yp/group
# $FreeBSD: src/etc/group,v 1.19.2.3 2002/06/30 17:57:17 des Exp $
#
wheel:*:0:root,trevor
staff:*:20:root
win32::1001:melanie,sarah
os2::1002:
dos::1003:
unix::1004:
music::1005:melanie,sarah
gamers::1006:
devel::1007:trevor
wwwdevel::15000:wwwglobal,trevor
All the rest (see attachment) are from /etc/group.
Jens
$VAR1 = [
'wheel',
'*',
0,
'root trevor mel'
];
$VAR1 = [
'daemon',
'*',
1,
''
];
$VAR1 = [
'kmem',
'*',
2,
''
];
$VAR1 = [
'sys',
'*',
3,
''
];
$VAR1 = [
'tty',
'*',
4,
''
];
$VAR1 = [
'operator',
'*',
5,
'root'
];
$VAR1 = [
'mail',
'*',
6,
''
];
$VAR1 = [
'bin',
'*',
7,
''
];
$VAR1 = [
'news',
'*',
8,
''
];
$VAR1 = [
'man',
'*',
9,
''
];
$VAR1 = [
'games',
'*',
13,
''
];
$VAR1 = [
'ftp',
'*',
14,
''
];
$VAR1 = [
'staff',
'*',
20,
''
];
$VAR1 = [
'sshd',
'*',
22,
''
];
$VAR1 = [
'smmsp',
'*',
25,
''
];
$VAR1 = [
'mailnull',
'*',
26,
''
];
$VAR1 = [
'guest',
'*',
31,
''
];
$VAR1 = [
'bind',
'*',
53,
''
];
$VAR1 = [
'proxy',
'*',
62,
''
];
$VAR1 = [
'authpf',
'*',
63,
''
];
$VAR1 = [
'_pflogd',
'*',
64,
''
];
$VAR1 = [
'_dhcp',
'*',
65,
''
];
$VAR1 = [
'uucp',
'*',
66,
''
];
$VAR1 = [
'dialer',
'*',
68,
''
];
$VAR1 = [
'network',
'*',
69,
''
];
$VAR1 = [
'audit',
'*',
77,
''
];
$VAR1 = [
'www',
'*',
80,
''
];
$VAR1 = [
'oper',
'*',
200,
'root trevor pgsql'
];
$VAR1 = [
'nogroup',
'*',
65533,
''
];
$VAR1 = [
'nobody',
'*',
65534,
''
];
$VAR1 = [
'messagebus',
'*',
556,
''
];
$VAR1 = [
'polkit',
'*',
559,
''
];
$VAR1 = [
'haldaemon',
'*',
560,
''
];
$VAR1 = [
'avahi',
'*',
558,
''
];
$VAR1 = [
'gdm',
'*',
92,
''
];
$VAR1 = [
'pgsql',
'*',
70,
''
];
smmsp is returned more than once (No 2 comes here)
$VAR1 = [
'smmsp',
'*',
25,
''
];
guest is returned more than once (No 2 comes here)
$VAR1 = [
'guest',
'*',
31,
''
];
authpf is returned more than once (No 2 comes here)
$VAR1 = [
'authpf',
'*',
63,
''
];
$VAR1 = [
'devel',
'',
1007,
'trevor'
];
tty is returned more than once (No 2 comes here)
$VAR1 = [
'tty',
'*',
4,
''
];
bin is returned
pf behavior question
Hi; System: 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Fri Jun 11 09:41:37 BRT 2010 i386 The question is about how pf acts on an specific situation. Supose I have the following rules: pass in log inet proto tcp from $int_if to any port 8021 flags S/SA keep state tag test rule 2 rule 3 . . rule n pass in log quick on $int_if inet proto tcp tagged test keep state queue (ftp) Suppose the packet matches the first rule. According to what I red about pf, it will keep parsing the rules (no quick on the first rule). When it reaches the last rule, the tag will match and the packet will pass. I don't believe I'll have 2 state table entries for the same packet after the last rule matches. or will I? What is the proper way to use the tag created on the first rule, as far as the state table is concerned? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winfoes FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
pf behavior question (addendum)
Sorry. Forgot to ask: Will the packet be actually tagged on the first rule, even though rule parsing continues? will it reach the last rule already tagged? Thanks again. Hi; System: 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Fri Jun 11 09:41:37 BRT 2010 i386 The question is about how pf acts on an specific situation. Supose I have the following rules: pass in log inet proto tcp from $int_if to any port 8021 flags S/SA keep state tag test rule 2 rule 3 . . rule n pass in log quick on $int_if inet proto tcp tagged test keep state queue (ftp) Suppose the packet matches the first rule. According to what I red about pf, it will keep parsing the rules (no quick on the first rule). When it reaches the last rule, the tag will match and the packet will pass. I don't believe I'll have 2 state table entries for the same packet after the last rule matches. or will I? What is the proper way to use the tag created on the first rule, as far as the state table is concerned? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winfoes FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
pf behavior question (addendum)
Sorry. Forgot to ask: Will the packet be actually tagged on the first rule, even though rule parsing continues? will it reach the last rule already tagged? Thanks again. Hi; System: 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Fri Jun 11 09:41:37 BRT 2010 i386 The question is about how pf acts on an specific situation. Supose I have the following rules: pass in log inet proto tcp from $int_if to any port 8021 flags S/SA keep state tag test rule 2 rule 3 . . rule n pass in log quick on $int_if inet proto tcp tagged test keep state queue (ftp) Suppose the packet matches the first rule. According to what I red about pf, it will keep parsing the rules (no quick on the first rule). When it reaches the last rule, the tag will match and the packet will pass. I don't believe I'll have 2 state table entries for the same packet after the last rule matches. or will I? What is the proper way to use the tag created on the first rule, as far as the state table is concerned? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winfoes FREE) -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winfoes FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf behavior question
On 16/07/2010 18:22:04, Mario Lobo wrote: Hi; System: 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Fri Jun 11 09:41:37 BRT 2010 i386 The question is about how pf acts on an specific situation. Supose I have the following rules: pass in log inet proto tcp from $int_if to any port 8021 flags S/SA keep state tag test rule 2 rule 3 . . rule n pass in log quick on $int_if inet proto tcp tagged test keep state queue (ftp) Suppose the packet matches the first rule. According to what I red about pf, it will keep parsing the rules (no quick on the first rule). When it reaches the last rule, the tag will match and the packet will pass. I don't believe I'll have 2 state table entries for the same packet after the last rule matches. or will I? What is the proper way to use the tag created on the first rule, as far as the state table is concerned? Correct, essentially. No, you won't end up with two entries in the state table from this -- it's only the last matching rule that causes the state table to be modified. In fact, you simply can't have two state table entries for the same (i/f, proto, srcaddr, srcport, destaddr, destport) tuple, because those six quantities are together used as the index into the state table. (Note: i/f is usually 'all' unless you've 'set state-policy if-bound' or equivalent, so generating state on one interface allows a packet to pass on any interface.) You don't get much from using tagging in the case you show -- as you've only got one rule to apply tags you might as well have let that been the place where you decided to pass or block the packet. Tagging is a lot more useful where you need several different rules to identify a particular class of traffic: you can apply the tag from several different matching rules, and then have just one rule to express your policy for that class of traffic. See the example in http://www.openbsd.org/faq/pf/tagging.html which gives a pretty good idea how it all works. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: pf behavior question
On Friday 16 July 2010 20:58:31 Matthew Seaman wrote:
On 16/07/2010 18:22:04, Mario Lobo wrote:
Hi;
System: 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Fri Jun 11 09:41:37 BRT
2010 i386
The question is about how pf acts on an specific situation.
Supose I have the following rules:
pass in log inet proto tcp from $int_if to any port 8021
flags S/SA keep state tag test
rule 2
rule 3 .
.
rule n
pass in log quick on $int_if inet proto tcp tagged test keep state queue
(ftp)
Suppose the packet matches the first rule.
According to what I red about pf, it will keep parsing the rules (no
quick on the first rule). When it reaches the last rule, the tag will
match and the packet will pass.
I don't believe I'll have 2 state table entries for the same packet after
the last rule matches. or will I?
What is the proper way to use the tag created on the first rule, as far
as the state table is concerned?
Correct, essentially.
No, you won't end up with two entries in the state table from this --
it's only the last matching rule that causes the state table to be
modified. In fact, you simply can't have two state table entries for
the same (i/f, proto, srcaddr, srcport, destaddr, destport) tuple,
because those six quantities are together used as the index into the
state table. (Note: i/f is usually 'all' unless you've 'set
state-policy if-bound' or equivalent, so generating state on one
interface allows a packet to pass on any interface.)
Ok. That confirms my suspicions.
You don't get much from using tagging in the case you show -- as you've
only got one rule to apply tags you might as well have let that been the
place where you decided to pass or block the packet. Tagging is a lot
more useful where you need several different rules to identify a
particular class of traffic: you can apply the tag from several
different matching rules, and then have just one rule to express your
policy for that class of traffic. See the example in
http://www.openbsd.org/faq/pf/tagging.html which gives a pretty good
idea how it all works.
I think that my case applies to that exactly
Take the following excerpt from my pf.conf:
I tag the packets on their way in from lan. The ports are queued on their way
out, prioritizing the ports accordingly.
The tag ftp_proxy is put there by the ftp-proxy program, which is why this
question came up. I want ftp packets to have the lowest priority, so allowing
ftp-proxy to tag them, I can direct them to any queue I want on their way in
or out.
ftp-proxy insert these rules (real example):
@0 pass in log inet proto tcp from 172.16.3.145 to 129.128.5.191 port =
61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0
@1 pass out log inet proto tcp from 189.12.120.11 to 129.128.5.191 port =
61076 flags S/SA keep state (max 1) tag ftp_proxy rtable 0
look at the outlined pass out rule bellow. These 2 rules will match but
parsing continues until they reach the pass out rule, where I queue them where
I want. At least that the idea.
I am using if-bound and I have altq on both lan_if and ext_if.
Allow_tcp_ports_lan = {21, 53, 67, 68, 80, 443, 143, 445, 587, 995, 1433,
1863, 110, 3000, 5061, 1723, 3389, 8933, 135}
Allow_tcp_ports_lab = {53, 80, 443, 3389}
# from LAN ---
pass in log quick on $lan_if inet proto tcp from $lan_if:network to !$lan_if
port $Allow_tcp_ports_lan keep state tag to_out
pass in log quick on $lan_if inet proto udp from $lan_if:network to !$lan_if
port $Allow_udp_ports_lan keep state tag to_out
# To INTERNET--
pass out log quick on $ext_if inet proto tcp from any to any port 8933
tagged to_out modulate state queue (ssh_bulk, ack)
pass out log quick on $ext_if inet proto tcp from any to any port pptp
tagged to_out modulate state queue (ssh_bulk, ack)
pass out log quick on $ext_if inet proto tcp from any to any port ssh
tagged to_out modulate state queue (ssh_bulk, ssh_login)
pass out log quick on $ext_if inet proto tcp from any to any port smtp
tagged to_out modulate state queue (mail, ack)
pass out log quick on $ext_if inet proto tcp from any to any port http
tagged to_out modulate state queue (web)
pass out log quick on $ext_if inet proto tcp from any to any port https
tagged to_out modulate state queue (web)
pass out log quick on $ext_if inet proto tcp from any to any port 444
tagged to_out modulate state queue (web)
pass out log quick on $ext_if inet proto tcp from any to any port 81
tagged to_out modulate state queue (web)
pass out log quick on $ext_if inet proto tcp from any to any port 82
tagged to_out modulate state queue (web)
pass out log quick on $ext_if inet proto tcp from any to any port domain
tagged to_out modulate state queue (dns, ack)
pass out log quick on $ext_if inet proto udp from any to any port domain
tagged
Re: Re : cannot install opera
It is interesting why they are waiting for update if they found vulnerabilities on June 25th and version 10.11 was out long time ago. On Fri, Jul 16, 2010 at 2:44 AM, Alexandre L. axel...@ymail.com wrote: Yesterday, I have written to the maintainer of the Opera port, and he gave me this link : http://www.freebsd.org/cgi/query-pr.cgi?pr=148294 The port update is in the pipes ;) Alexandre. --- En date de : Ven 16.7.10, zaxis z_a...@163.com a écrit : De: zaxis z_a...@163.com Objet: cannot install opera À: freebsd-questions@freebsd.org Date: Vendredi 16 juillet 2010, 7h14 sudo portsnap fetch update cd /usr/ports/www/opera /usr/ports/www/operasudo make install clean Password: === opera-10.10.20091120_2 has known vulnerabilities: = opera -- Data URIs can be used to allow cross-site scripting. Reference: http://portaudit.FreeBSD.org/77b9f9bc-7fdf-11df-8a8d-0008743bf21a.html = Please update your ports tree and try again. *** Error code 1 Stop in /media/G/usr/ports/www/opera. does it mean the oepra vulnerabilities has not been fixed ? - e^(π⋅i) + 1 = 0 -- View this message in context: http://old.nabble.com/cannot-install-opera-tp29180746p29180746.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
