remote connection to mysql
Hi,
I'm trying to connect remotely to my database server. It is MySQL 4.1.7
which I install from ports. I created a user with permissions to
connect from any remote location. I'm using Perl DBI, like this:
use DBI;
my $dbh = DBI-connect(
'dbi:mysql:[EMAIL PROTECTED]:3306',
'user', 'passwd', {
RaiseError = 1, AutoCommit = 1
}
);
Yet I continue to receive connection errors. Can't connect to the MySQL
server on 3306 (10061). I'v verified that the server is listening on
the port. I also found some info on google about Perl DBD::mysql
problems. I tried resetting the user's password with the OLD_PASSWORD
option. Nothing works. Can anyone help???
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remote connection to mysql
[EMAIL PROTECTED] wrote:
use DBI;
my $dbh = DBI-connect(
'dbi:mysql:[EMAIL PROTECTED]:3306',
'user', 'passwd', {
RaiseError = 1, AutoCommit = 1
}
);
Yet I continue to receive connection errors. Can't connect to
the MySQL server on 3306 (10061). I'v verified that the server is
listening on the port. I also found some info on google about
Perl DBD::mysql problems. I tried resetting the user's password
with the OLD_PASSWORD option. Nothing works. Can anyone help???
Error code 10061 = connection refused. Are you sure there is no firewall
in place blocking access to port 3306? Can you telnet to host.org 3306?
If so, you might want to try changing your script like this:
use DBI;
my $dbh = DBI-connect(
'dbi:mysql:database=DATABASE;host=REMOTE_IP;port=3306',
'user', 'passwd', { RaiseError = 1, AutoCommit = 1 }
);
Otherwise if you are running 4.10 you might want to use sysctl to set
net.inet.ip.portrange.randomized to 0.
Use may also want to use sockstat to make sure your script is actually
trying to connect to the right IP.
ALeine
___
WebMail FREE http://mail.austrosearch.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remote connection to mysql
On Mon, 21 Feb 2005, Matt wrote: Hi, I'm trying to connect remotely to my database server. It is MySQL 4.1.7 which I install from ports. I created a user with permissions to connect from any remote location. I'm using Perl DBI, like this: Are you sure that you set up MySQL to accept TCP connections? I think it defaults to local sockets only; you can verify by running netstat -na and seeing if there's anything listening on port 3306. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error in my C programming
Peter Jeremy wrote: OK it was all to do with the comments it did not like the //comments ARRGG the rest of the errors were bogus as soon as I changed EVERY comment over to the ANSI C /*comments*/ it now works (oh and removed the #pragma directives from a c compiler for the AVR uC I will have to put all the different complier directives in different #ifdef tags :) Thanks all for your help it is really apreciated (I may actually go to bed soon lol) If anyone can recomend online resources for Makefiles I would apreciate it :) Regards, Kat. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 18/02/2005 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error in my C programming
[EMAIL PROTECTED] wrote: If anyone can recomend online resources for Makefiles I would apreciate it :) How about a source which is already on your disk? :-) zcat /usr/share/doc/psd/12.make/paper.ascii.gz | less You may also want to study the first chapter of the FreeBSD System Programming book at: http://www.khmere.com/freebsd_book/html/ch01.html Reading about the alternatives might be a good idea as well: http://developers.slashdot.org/article.pl?sid=05/01/29/2033230 ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vn_fullpath()
On Sun, 20 Feb 2005, Igor Shmukler wrote: I was wondering if anyone has figured a way to make vn_fullpath() reliable? It depends a lot on the requirements. There are some nasty edge cases where the process of determining a name for an object can be quite expensive. Here's one of them: ln /usr/local/etc/apache/httpd.conf /usr/local/etc/apache.old/httpd.conf reboot apachectl start rm /usr/local/etc/apache/httpd.conf Now generate the name of the file that Apache has open. Note that you can't just look in the name cache, because the object has a name but the name used to open the object has been invalidated. And UFS even knows it has a name, because the link count remains non-zero when the unlink of one of the names occurs -- but the only way it can find the other name is to search the file system. So the first thing to do is to decied what your requirements are: are you willing to fail in the edge cases like the above? If so, life is a lot easier :-). Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vn_fullpath()
This is an interesting discussion. As far as I understand, a function for performing reverse (object - filename) lookup is being discussed. Having such a function would help me with implementation of my custom changes-tracking filesystem (I once started a discussion of such a thing on this list). I don't think i'm able to actually help with making vn_fullpath() reliable, but I'm definitely the one who's interested in the end result :) With such a call at hand i could actually begin writing my filesystem (changes-tracking wrapper for UFS). As to hard links, they will be simply disallowed. What are the other edge cases, beside hard links, that need to be taken care of? Robert Watson wrote: On Sun, 20 Feb 2005, Igor Shmukler wrote: I was wondering if anyone has figured a way to make vn_fullpath() reliable? It depends a lot on the requirements. There are some nasty edge cases where the process of determining a name for an object can be quite expensive. Here's one of them: ln /usr/local/etc/apache/httpd.conf /usr/local/etc/apache.old/httpd.conf reboot apachectl start rm /usr/local/etc/apache/httpd.conf Now generate the name of the file that Apache has open. Note that you can't just look in the name cache, because the object has a name but the name used to open the object has been invalidated. And UFS even knows it has a name, because the link count remains non-zero when the unlink of one of the names occurs -- but the only way it can find the other name is to search the file system. So the first thing to do is to decied what your requirements are: are you willing to fail in the edge cases like the above? If so, life is a lot easier :-). Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
4M page size
Is there a way currently to utilize 4M page size with FreeBSD for large data set programs (to optimize TLB misses)? Pete ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4M page size
Petri Helenius wrote: Is there a way currently to utilize 4M page size with FreeBSD for large data set programs (to optimize TLB misses)? Pete FreeBSD/i386 uses 4MB pages to hold the kernel text and data, but there is no way (to my knowledge) to ask the pmap layer for a 4MB page after that either from the kernel or from userland. However, it's also my understanding that most non-Xeon CPUs only have a 4kb TLB, and 4MB pages are just broken down into 4kb chunks for it. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: vn_fullpath()
Robert and David, Thank you for your help. It depends a lot on the requirements. There are some nasty edge cases where the process of determining a name for an object can be quite expensive. Here's one of them: ln /usr/local/etc/apache/httpd.conf /usr/local/etc/apache.old/httpd.conf reboot apachectl start rm /usr/local/etc/apache/httpd.conf Now generate the name of the file that Apache has open. Note that you can't just look in the name cache, because the object has a name but the name used to open the object has been invalidated. And UFS even knows it has a name, because the link count remains non-zero when the unlink of one of the names occurs -- but the only way it can find the other name is to search the file system. So the first thing to do is to decied what your requirements are: are you willing to fail in the edge cases like the above? If so, life is a lot easier :-). I guess I am willing to fail :). Perhaps in some distant future, we will look into the nasty corner cases, but for now, as long as I get a name, it will do. We don't even mind the hardlinks so much, but we cannot afford to use existing vn_fullpath() because it does not guarantee anything. Thank you, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: vn_fullpath()
On Mon, 21 Feb 2005, Igor Shmukler wrote: So the first thing to do is to decied what your requirements are: are you willing to fail in the edge cases like the above? If so, life is a lot easier :-). I guess I am willing to fail :). Perhaps in some distant future, we will look into the nasty corner cases, but for now, as long as I get a name, it will do. We don't even mind the hardlinks so much, but we cannot afford to use existing vn_fullpath() because it does not guarantee anything. There are a couple of issues to look at, if we can allow some obscure edge cases to fail, but want it to generally work: (1) File systems that don't use the centralized name cache facility, such as procfs and devfs. (2) What to do when useful paths fall out of the name cache. I think the answer to (1) is to let those file systems simply provide a vnode operation to answer the question: they're almost always synthetic file systems, or they would be using the cache. So I'm almost thinking: VOP_GETPATH(vp, char *buf) The call would say to the file system Tell me the path from your root to the vnode in question. On the (2) front, I think there are a couple of possibilities -- the decision to let intermediate paths fall out of the name cache is an explicit design choice to reduce the vnode burden on the system. We can either back off that design choice forcing intermediate nodes to generally remain in the cache, or we can accept it and address it. My leaning is to add a new rule: the last directory used to reach a file must not fall out of the cache if the file hasn't fallen out of the cache -- with this in place, we can generate path names for most objects by walking back up the tree if elements are missing, either directly, or by asking the file system using the above call. It's the last step from the file back to a parent directory that is the hardest. Alternatively, we can back off dropping the intermediate nodes and see to what extent that hurts vs. helps. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remote connection to mysql
Mike Silbersack wrote: On Mon, 21 Feb 2005, Matt wrote: Hi, I'm trying to connect remotely to my database server. It is MySQL 4.1.7 which I install from ports. I created a user with permissions to connect from any remote location. I'm using Perl DBI, like this: Are you sure that you set up MySQL to accept TCP connections? I think it defaults to local sockets only; you can verify by running netstat -na and seeing if there's anything listening on port 3306. Mike Silby Silbersack Thanks for your reply. I do see this in netstat output: tcp4 0 0 192.168.2.23.3306 *.*LISTEN ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: vn_fullpath()
On 21 Feb, Robert Watson wrote: On Mon, 21 Feb 2005, Igor Shmukler wrote: So the first thing to do is to decied what your requirements are: are you willing to fail in the edge cases like the above? If so, life is a lot easier :-). I guess I am willing to fail :). Perhaps in some distant future, we will look into the nasty corner cases, but for now, as long as I get a name, it will do. We don't even mind the hardlinks so much, but we cannot afford to use existing vn_fullpath() because it does not guarantee anything. There are a couple of issues to look at, if we can allow some obscure edge cases to fail, but want it to generally work: (1) File systems that don't use the centralized name cache facility, such as procfs and devfs. (2) What to do when useful paths fall out of the name cache. I think the answer to (1) is to let those file systems simply provide a vnode operation to answer the question: they're almost always synthetic file systems, or they would be using the cache. So I'm almost thinking: VOP_GETPATH(vp, char *buf) The call would say to the file system Tell me the path from your root to the vnode in question. On the (2) front, I think there are a couple of possibilities -- the decision to let intermediate paths fall out of the name cache is an explicit design choice to reduce the vnode burden on the system. We can either back off that design choice forcing intermediate nodes to generally remain in the cache, or we can accept it and address it. My leaning is to add a new rule: the last directory used to reach a file must not fall out of the cache if the file hasn't fallen out of the cache -- with this in place, we can generate path names for most objects by walking back up the tree if elements are missing, either directly, or by asking the file system using the above call. It's the last step from the file back to a parent directory that is the hardest. Alternatively, we can back off dropping the intermediate nodes and see to what extent that hurts vs. helps. I seem to recall that DragonFly keeps the intermediate nodes. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: vn_fullpath()
: tree if elements are missing, either directly, or by asking the file : system using the above call. It's the last step from the file back to a : parent directory that is the hardest. Alternatively, we can back off : dropping the intermediate nodes and see to what extent that hurts vs. : helps. : :I seem to recall that DragonFly keeps the intermediate nodes. There's no way to backport that, it would be hundreds of man hours of work. DragonFly uses a totally different namecache topology now, one that is mandatory and which guarentees the existance of intermediate nodes. You'd have to implement something similar to libc's getcwd code. e.g. .. through and scan each directory to find the matching inode if the namecache entry is not present. It actually wouldn't be too hard to do. It wouldn't be efficient, but vn_fullpath() is rarely used so it shouldn't be a problem. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] Dangerous jail()-ioctl interactions.
Hello hackers, I would like to let you know I've been doing [partial] audit of ioctl() code. There are some places, which may interest you. These are: sys/cam/cam_xpt.c sys/contrib/ipfilter/netinet/ip_fil.c sys/contrib/pf/net/pf_ioctl.c sys/dev/ata/ata-all.c sys/dev/md/md.c sys/geom/geom_ctl.c Those files contain ioctl()s, which let us to interact between jailed processes and each of these subsystems. Although files like /dev/mdctl should not appear in /dev with normal DEVFS rulesets, I think it would be better if FreeBSD had those ioctl() disabled within jail()ed environment. There is probably one reason for keeping ipf/pf, since someone may want fetch information about NATed connections. How to repeat? Reproducing is very simple. Test environment: # jail / hostname 127.0.0.1 /bin/csh After this step you can monipulate ATA devices: # atacontrol detach number Create/remove md(4) devices: # mdconfig -a -t malloc -s 100M # mdconfig -d -u md0 Manipulate cam(4) devices: # camcontrol reset cd0 # camcontrol eject cd0 Manipulate gbde devices: # mdconfig -a -t malloc -s 10M # gbde Manipulate ipnat/ipf/pf rules: # ipnat -f /etc/ipnat.conf # ipnat -CF a # pfctl -f /etc/pf.some.rules # ipf -f /etc/ipf.some.rules Patches with simple suser() tests added are available at: (sys/cam/cam_xpt.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.1.jail (sys/contrib/ipfilter/netinet/ip_fil.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.2.jail (/usr/src/sys/contrib/pf/net/pf_ioctl.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.3.jail (/usr/src/sys/dev/ata/ata-all.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.4.jail (If someone would like to commit it, I can also write style patch). (/usr/src/sys/dev/md/md.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.5.jail (/usr/src/sys/geom/geom_ctl.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.6.jail And comments are welcome. If you find some of these patches useful, please let me know. Regards, -- * Wojciech A. Koszek [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel threads libc
Hello all, I'm forced to implement kernel threads in application not via LinuxThreads library (because it doesn't compile on FreeBSD 4.10 with gcc-3.4.4, too much errors while processing /usr/src code), but using rfork_thread(3). And the main question I currently stuck on is which libc functions I need to wrap to make them thread-safe and reentrant on multiprocessor systems, since rfork_thread(3)s are created with RFMEM flag and libc_r is not used. Could somebody please give ideas or point me to the appropriate reading? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
