Re: ipfw confusion
You might turn on logging and post the logs of what is being blocked. Sometimes things are being blocked by rules you do not expect. On Mon, Aug 19, 2013 at 4:18 PM, Gary Aitken vagab...@blackfoot.net wrote: On 08/19/13 00:36, Jason Cox wrote: Are you sure that your DNS requests are over TCP? DNS primarily uses UDP to serve requests. TCP is used when the response data size exceeds 512 bytes (I think), or for tasks such as zone transfers. I know a few resolver implementations use TCP for all queries, but most I have used not. You might want to add rules to allow UDP as well. There are identical rules included for udp: 21149 allow udp from any to 12.32.44.142 dst-port 53 in via tun0 keep-state 21169 allow udp from any to 12.32.36.65 dst-port 53 in via tun0 keep-state One of the requests which is being refused is a zone transfer request from a secondary which is a tcp request. Others are probably udp. On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken vagab...@blackfoot.net wrote: I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out. ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? Is there a problem if the incoming rule is for tun0, which gets passed to named since 12.32.44.142 is on the physical machine running named, but named pumps its response out on 12.32.36.65, relying on routing to get it to the right place, and that fails to match the state tracking mechanism which started with 12.32.44.142? ___ 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
Re: ipfw confusion
On Mon, Aug 19, 2013 at 1:06 AM, Gary Aitken vagab...@blackfoot.net wrote: ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any What am I missing? Do you have a check-state rule earlier in your rules? 1000 check-state Dan ___ 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
svnsync and local changes
Back when cvsup was in use, I mirrored the ports with cvsup-mirror. Then I could add files and make changes. My servers used my repository so they always had my changes and I only had to do them once. I am trying to replicate the same setup now that subversion is used. I've set up svnsync, and that works fine. I was able to add files with 'svn add' and 'svn commit'. My servers properly download all the new files. The problem is I can no longer use svnsync. Now it gives me Destination HEAD (316955) is not the last merged revision (316951).I've tried removing my files with 'svn rm', but that just changes the number in the error. Is there some way to get this to work with svnsync? Is there a better way for me to have a local repository that includes local changes? Thanks, Dan ___ 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: getpwnam_r returns EINVAL on FreeBSD 8.3
On Mon, Dec 3, 2012 at 5:54 PM, Dan Lists lists@gmail.com wrote:
After upgrading a server from FreeBSD 7.3 to FreeBSD 8.3 I noticed
this bug. Since upgrading, getpwnam_r is acting inconsistently. If I
look up a user that does not exist and the name is 16 characters or
less, getpwnam_r returns 0 and the result is NULL. If the name is
more than 16 characters, getpwnam_r returns EINVAL. Everything works
correctly for users that exist.
I was incorrect. The behavior of getpwnam_r is the same on 7.3 and
8.3. The software I was testing acted differently on the two
versions.
This only happens when the nsswitch.conf passwd: line contains files.
You need to use files if you are using another module such as msql or
ldap. The problem exists without the other modules listed. For
example:
passwd: files
I would like to emphasize that this does NOT happen when passwd: is
set to compat. I believe this is a bug. getpwnam_r should have the
same return values (or errno for getpwnam) whether nsswitch.conf has
compat or files. If there is a really good reason for them to be
different, it should be documented.
Below is a simple test program. Set passwd: to files in nsswitch.conf
and run the program. Any idea how to fix this bug with getpwnam_r?
#include stdio.h
#include sys/types.h
#include pwd.h
main()
{
lookup(doesnotexist);
lookup(doesnotexisty);
}
int lookup( char *name)
{
struct passwd pwd;
char buffer[1024];
struct passwd *result;
int err;
printf(\nLooking up: %s\n, name);
err = getpwnam_r(name, pwd, buffer, sizeof(buffer), result);
if( err != 0 ){
printf(Return code: %d\n, err);
}else if( result == 0 ){
printf(Returned no result!\n);
}else{
printf(Returned: %s (%d)\n, result-pw_name, result-pw_uid);
}
}
___
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
getpwnam_r returns EINVAL on FreeBSD 8.3
After upgrading a server from FreeBSD 7.3 to FreeBSD 8.3 I noticed
this bug. Since upgrading, getpwnam_r is acting inconsistently. If I
look up a user that does not exist and the name is 16 characters or
less, getpwnam_r returns 0 and the result is NULL. If the name is
more than 16 characters, getpwnam_r returns EINVAL. Everything works
correctly for users that exist.
This only happens when the nsswitch.conf passwd: line contains files.
You need to use files if you are using another module such as msql or
ldap. The problem exists without the other modules listed. For
example:
passwd: files
Below is a simple test program. Set passwd: to files in nsswitch.conf
and run the program. Any idea how to fix this bug with getpwnam_r?
#include stdio.h
#include sys/types.h
#include pwd.h
main()
{
lookup(doesnotexist);
lookup(doesnotexisty);
}
int lookup( char *name)
{
struct passwd pwd;
char buffer[1024];
struct passwd *result;
int err;
printf(\nLooking up: %s\n, name);
err = getpwnam_r(name, pwd, buffer, sizeof(buffer), result);
if( err != 0 ){
printf(Return code: %d\n, err);
}else if( result == 0 ){
printf(Returned no result!\n);
}else{
printf(Returned: %s (%d)\n, result-pw_name, result-pw_uid);
}
}
___
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: Newbie question: Why aren't my cron jobs running?
On Tue, Jun 12, 2012 at 12:06 PM, Polytropon free...@edvax.de wrote: On Tue, 12 Jun 2012 08:29:02 -0500, Mark Felder wrote: On Tue, 12 Jun 2012 00:06:21 -0500, Robert Bonomi bon...@mail.r-bonomi.com wrote: Comment: using a leading zero on the numeric fields is a BAD IDEA(tm) -- you are *strongly* encocuraged to remove them. Yes, that means numbers will not be column aligned, but it is a small price to pay to avoid the hair-tearing that =will= ensue when using it bites you. Any other info on this? I've never heard of this before and I've never seen an issue using leading zeroes on the minutes value. There are some specific interpretations that _may_ be interpreted according to the C rules, e. g. prefix 0x- for hexadecimal or 08- for octal notation. For example, 083 != 83, just as 0x83 != 83. As it has been mentioned, spaces also have a significant meaning in crontabs, so they cannot be used everywhere to align data columns. The syntax of his crontab file is correct. Vixie cron does care about leading spaces, tabs, extra spaces, or leading zeros. Earlier versions of cron are much pickier about the crontab file. The cron logs show that it is starting his jobs at the correct times. It is far more likely that there is a problem with the scripts. A very common cause of problems with scripts run from cron is that they do not inherit your environment. Do the scripts run from the command line? If the do, then the problem is most likely something in your environment that the scripts need. ___ 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
USA Anonymous CVS
From http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html USA: anon...@anoncvs1.freebsd.org:/home/ncvs (For ssh, use ssh version 2 and no password is required.) SSH2 HostKey: 2048 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62 /etc/ssh/ssh_host_dsa_key.pub Example A-2. Using SSH to Check Out the src/ Tree: % cvs -d anon...@anoncvs1.freebsd.org:/home/ncvs co src The authenticity of host 'anoncvs1.freebsd.org (216.87.78.137)' can't be established. DSA key fingerprint is 53:1f:15:a3:72:5c:43:f6:44:0e:6a:e9:bb:f8:01:62. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs1.freebsd.org' (DSA) to the list of known hosts. However, when I acutally issue the command, I get a different DSA key, different IP, and it will not accept any password: # cvs -d anon...@anoncvs1.freebsd.org:/home/ncvs co src The authenticity of host 'anoncvs1.freebsd.org (96.47.72.116)' can't be established. DSA key fingerprint is 4e:bc:48:a0:e1:27:0a:62:c8:da:45:31:d4:ad:b2:00. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs1.freebsd.org' (DSA) to the list of known hosts. Password: Password: Password: Permission denied (publickey,keyboard-interactive). cvs [checkout aborted]: end of file from server (consult above messages if any) Is the USA anonymous CVS server no longer operational? Thanks, Dan ___ 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
