DBI, Dynaloader, mod_perl, and Undefined symbol "PL_dowarn"
I just experienced an issue where I upgraded MySQL, and had to reinstall the DBD::Mysql module to match the new client libraries (libmysqlclient.so.10 - I was getting messages about an ISA directive not found). After reinstalling the MySQL module, DBI began to spew errors at me when I tried to restart Apache. I was running mod_perl 1.24, and after reinstalling DBI, I finally figured out that I needed to upgrade mod_perl (I went to mod_perl 1.26) and this fixed the problem. This is pretty much just a helping piece for anyone searching for this error. - Jonathan
RE: Perl Sections: command_rec for directive `ISA' not found!
I previously posted the below, but after experiencing this same problem
after upgrading MySQL, I did some research and noticed that I had to
re-compile/re-install the Msql-Mysql-modules-1.2216.tar.gz package/module
when the libmysqlclient.so file got updated.
For instance, I first installed the perl module when I had MySQL 3.23.36,
which compiles libmysqlclient.so.6, and then I just upgraded to MySQL
3.23.47, which compiles/relies on libmysqlclient.so.10. I now had to
re-install the Msql-Mysql-modules package using the new libmysqlclient.so.10
file (I believe it was in the Makefile, but I could be wrong). After I did
that, everything worked fine.
- Jonathan
--- Original Message ---
Seeing that nobody answered your question or posted the answer, I had to
overcome this same problem. The problem was the Perl libraries that were
installed (or not installed). You need to reinstall / install the
Bundle::DBI package and the correct modules for it. In my case, I was trying
to dynamically build VirtualHost directives from a mySQL database. I
telnetted/ssh to the shell and typed the following:
su-2.04# perl -MCPAN -e shell
cpan> install Bundle::DBI
< Bundle gets installed >
cpan> install Msql-Mysql-modules-1.2216.tar.gz
< Package starts installing >
When it asked me if I wanted mSQL, mySQL, or both, I chose mySQL only.
It asked me where the subdirectory with the include files was, and it
defaulted to /usr/local. This caught me off-guard because mySQL was actually
installed in /usr/local/mysql and so I kept putting that directory, but it
kept failing. When I tried reinstalling, I left it at /usr/local and it went
through fine.
Now that the packages are installed, I had one more error to fix. In the
section, I had:
$dbh = DBI->connect('DBI:mysql: ..blah..blah...');
which had to be changed to
my $dbh = DBI->connect('DBI:mysql: ..blah..blah...');
Otherwise, Apache will not recognize the variables and will return an error
about commands and stuff.
Hope this helps!
Jonathan Hilgeman
RE: What the user in user agent means
True, sometimes people can be stupid and tinker around with their setups without knowing what they are doing, and they end up preventing themselves from being able to shop online, etc... Then they call the owner of the store and complain that their system doesn't work, and then the owners call us and tell us that the program we made for them does not work, and we have to reverse the chain and explain everything once again. In my opinion, that is working against the web. Someone can be identified uniquely and tracked without losing their privacy - history and personal information doesn't necessarily have to be linked to the identifier, which seems to be the big fuss. That is a browser issue. The whole purpose of web pages is to provide information EASILY to users. Now, if the user's program refuses to identify itself or allow the correct information to come in, whether by accident or intentionally, then that becomes a problem. It's like someone standing outside an unlocked door to a house they want to get in to, and they're shouting at the people inside, "Let me in! Let me in!" Seems like most web users are fairly stupid, and we can't expect them to learn everything. That's why the browsers should allow the web page programmers to help the users without them having to learn things. You can use the old adage, "Give a man a fish and you'll feed him for a day. Teach him to fish and you'll feed him for a lifetime." However, we just cannot teach everyone that visits unless they want to learn, and if they want to learn, they will most likely know before they even get to the site. Jonathan -Original Message- From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:19 AM To: [EMAIL PROTECTED] Subject: What the user in user agent means Why are we talking about tracking again? The user agent acts on behalf of the user. It is their agent. It is not your agent. Your content or program is a guest of the user agent, not its master. Learn to work with the web not against it.
RE: Concepts of Unique Tracking
Dialup users will be given high-speed connections using network cards and modems will be burned. It'll be like book-burning sessions all over again. Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 10:53 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Concepts of Unique Tracking JH> Let's take over the world and recompile all browsers to have them send out JH> the MAC address of thet network card. .. and if I'm dialup user :) JH> Jonathan JH> -Original Message- JH> From: Wim Kerkhoff [mailto:[EMAIL PROTECTED]] JH> Sent: Friday, May 25, 2001 10:42 AM JH> To: Jonathan Hilgeman JH> Cc: '[EMAIL PROTECTED]' JH> Subject: Re: Concepts of Unique Tracking JH> Jonathan Hilgeman wrote: >> >> What about client-specific information available in Javascript, like JH> screen >> resolution, size, etc...? Can that be accessed by tinkering with Apache a >> bit, or is it something only available because of the browser, since >> Javascript is dependent on the browser? JH> I briefly thought about suggesting something like that, or with JH> combination with the other headers that get sent in the HTTP request for JH> language, encoding, etc. However, think of the situations such as JH> computer labs, internet cafes, etc, where all computers are identical in JH> every aspect, with the exact same version of the browser, hard coded JH> screen resolutions (e.g. 800x600), etc, that the user can not change. JH> -- JH> Regards, JH> Wim Kerkhoff, Software Engineer JH> Merilus, Inc. -|- http://www.merilus.com JH> Email: [EMAIL PROTECTED] -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Concepts of Unique Tracking
Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan -Original Message- From: Wim Kerkhoff [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 10:42 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Concepts of Unique Tracking Jonathan Hilgeman wrote: > > What about client-specific information available in Javascript, like screen > resolution, size, etc...? Can that be accessed by tinkering with Apache a > bit, or is it something only available because of the browser, since > Javascript is dependent on the browser? I briefly thought about suggesting something like that, or with combination with the other headers that get sent in the HTTP request for language, encoding, etc. However, think of the situations such as computer labs, internet cafes, etc, where all computers are identical in every aspect, with the exact same version of the browser, hard coded screen resolutions (e.g. 800x600), etc, that the user can not change. -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED]
RE: Concepts of Unique Tracking
Actually, someone suggested HTTP authorization - does that require a cookie to work? Or after they are authorized, it simply keeps the session open in the browser...? Jonathan -Original Message- From: Brian Reichert [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 10:20 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Concepts of Unique Tracking On Fri, May 25, 2001 at 10:03:04AM -0700, Jonathan Hilgeman wrote: > Now, I'm assuming that Apache has full access to these incoming packets. > Therefore, they must also have access to this invisible identifier. Is it > possible to extract that identifier somehow by tinkering with Apache? Most NAT implemetations keep a hash of destination ports -> internal IP. To wit: > 1) Person behind the firewall sends out a request to a web server. Person _really_ establishes an outgoing TCP session with his NAT box. The NAT box notes his internal_IP:dest_port, sets up an outgoing TCP session to web server, notes it's own source port for that leg. > 4) The firewall receives the packets of data first, but now must send those > data packets to someone inside the firewall. Returning packets from the webserver come to that source port, NAT box looks up hash of: external_IP:source_port -> internal_IP:dest_port, and hands the packet in. > 5) The packets of data MUST have some unique identifier to let the firewall That would be the source port of the NAT box's outgoing connection. But: - each outgoing TCP connection from the internal host will use a different source port. - the request your web server is receiving may actaully (likely) be coming from a web cache somewhere. > > Jonathan > -- Brian 'you Bastard' Reichert<[EMAIL PROTECTED]> 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path
RE: Concepts of Unique Tracking
Actually, I had come up with a similar idea after I sent that one off. My idea was that packets had packet identifiers in their header or footer, and the packet identifiers were stored in the firewall and referenced to the computer inside the firewall, so whenever packets with that identifier came back, the firewall knew which computer to send it to. Oh well. What about client-specific information available in Javascript, like screen resolution, size, etc...? Can that be accessed by tinkering with Apache a bit, or is it something only available because of the browser, since Javascript is dependent on the browser? Jonathan -Original Message- From: Wim Kerkhoff [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 10:15 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Concepts of Unique Tracking Jonathan Hilgeman wrote: > Now, I'm assuming that Apache has full access to these incoming packets. > Therefore, they must also have access to this invisible identifier. Is it > possible to extract that identifier somehow by tinkering with Apache? The only thing that you can access from the webserver side is the REMOTE_ADDR and REMOTE_PORT. IP masquarding is handled only by the firewall that is doing the masquarding: the web server and browser have no idea that this is happening. The firewall has a table that keeps track of open TCP connections, so that when it receives data on the outside port (e.g. 61172) it knows to rewrite the packet and send it off back to the inside client (e.g. 192.168.1.42:49372) that created the initial TCP connection. This is one of primary reasons that cookies exist. -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED]
Concepts of Unique Tracking
Okay, after I think about it, there must be a way to identify a unique user, even if they are behind a firewall. Let's run through this process: 1) Person behind the firewall sends out a request to a web server. 2) The firewall intercepts that request, masks the person's IP address and lets the request keep going out. 3) The web server receives the request and sends back packets of data to the IP of the user, which is really the IP of the firewall now. 4) The firewall receives the packets of data first, but now must send those data packets to someone inside the firewall. 5) The packets of data MUST have some unique identifier to let the firewall know who requested the data in the first place. Now, I'm assuming that Apache has full access to these incoming packets. Therefore, they must also have access to this invisible identifier. Is it possible to extract that identifier somehow by tinkering with Apache? Jonathan
RE: Apache::Session / No-Cookie-Tracking
The feeling of magic only lasts until you know how it's done, and I have seen the light. What happens is that they use a per-session cookie, so it doesn't appear in my temp folder. But, if per-session cookies are disabled, then it relies on the IP address. I guess that is better than just one method, but I think I may use the same method, but base the no-cookie method on both IP address AND HTTP_USER_AGENT to try to make things more unique. Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:35 AM To: Jonathan Hilgeman Subject: Re: Apache::Session / No-Cookie-Tracking JH> Sure - I believe in magic, depending on your definition of it. I KNOW JH> there's a 4th method, because I've seen it work. There is an e-commerce web JH> site which uses an outside cart programmed in CGI (Perl?). The original web JH> site passes no identifying marks such as the session ID through the URL or JH> through the form's submit button to add an item to the cart. I know, because JH> I designed and created the web site. JH> [..skip..] Interesting. If you will say me url of your web site where you are using this outside cart probably I'll find how they do tracking. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
FW: Apache::Session / No-Cookie-Tracking
Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T990806951R5848 E cartidnum seems to be: $IP-Address + "T" + Unix-TimeStamp + "R" + Unknown number + "E" By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH> I want to be able to track visitors without the use of cookies. JH> I don't want to rely on IP address, because people behind proxies and JH> firewalls seem to have the same IP address. JH> I don't want to rely on a session ID variable being always present in the JH> URL, in case the window gets closed or changed. JH> Now, two questions: JH> 1) Will Apache::Session provide an environment variable like JH> HTTP_USER_AGENT that will contain an identifier that will always JH> be consistent for that specific user, despite proxies and JH> firewalls, and despite the changing/closing of windows? JH> 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Apache::Session / No-Cookie-Tracking
I want to be able to track visitors without the use of cookies. I don't want to rely on IP address, because people behind proxies and firewalls seem to have the same IP address. I don't want to rely on a session ID variable being always present in the URL, in case the window gets closed or changed. Now, two questions: 1) Will Apache::Session provide an environment variable like HTTP_USER_AGENT that will contain an identifier that will always be consistent for that specific user, despite proxies and firewalls, and despite the changing/closing of windows? 2) If not, does anyone know of a good way to do this? Jonathan
Perl Sections: command_rec for directive `ISA' not found!
Seeing that nobody answered your question or posted the answer, I had to
overcome this same problem. The problem was the Perl libraries that were
installed (or not installed). You need to reinstall / install the
Bundle::DBI package and the correct modules for it. In my case, I was trying
to dynamically build VirtualHost directives from a mySQL database. I
telnetted/ssh to the shell and typed the following:
su-2.04# perl -MCPAN -e shell
cpan> install Bundle::DBI
< Bundle gets installed >
cpan> install Msql-Mysql-modules-1.2216.tar.gz
< Package starts installing >
When it asked me if I wanted mSQL, mySQL, or both, I chose mySQL only.
It asked me where the subdirectory with the include files was, and it
defaulted to /usr/local. This caught me off-guard because mySQL was actually
installed in /usr/local/mysql and so I kept putting that directory, but it
kept failing. When I tried reinstalling, I left it at /usr/local and it went
through fine.
Now that the packages are installed, I had one more error to fix. In the
section, I had:
$dbh = DBI->connect('DBI:mysql: ..blah..blah...');
which had to be changed to
my $dbh = DBI->connect('DBI:mysql: ..blah..blah...');
Otherwise, Apache will not recognize the variables and will return an error
about commands and stuff.
Hope this helps!
Jonathan Hilgeman
RE: Sections in Apache Config
Okay, in that case, would there be a way for Perl/Apache to read in info
from a mySQL database and dynamically update itself? Something like:
connect_to_db(info);
$resultrows = db_query("SELECT FROM WHERE ");
foreach($resultrows as $UserName)
{
$VirtualHost = .
}
Can someone give me a good example of how to do that?
Thanks!
Jonathan
-Original Message-----
From: Jonathan Hilgeman [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 5:36 PM
To: '[EMAIL PROTECTED]'
Subject: Sections in Apache Config
Hi,
I've been trying to do this for some time but can't figure out how.
Basically I want a setup where anyone at www.UserName.domain.com or
UserName.domain.com will have their DocumentRoot set to
/www/httpd/html/UserName. So far I've tried this:
UseCanonicalName Off
if($HTTP_HOST =~ s/(?:www\.)?(.*)\.domain\.com//g)
{
$VirtualDocumentRoot = "/www/httpd/html/$1";
}
else
{
$VirtualDocumentRoot = '/www/httpd/html/%-3';
}
1;
The second $VirtualDocumentRoot line works fine, but I NEED to be able to
get the first line to work instead, using if possible.
Any guesses?
Jonathan
Sections in Apache Config
Hi,
I've been trying to do this for some time but can't figure out how.
Basically I want a setup where anyone at www.UserName.domain.com or
UserName.domain.com will have their DocumentRoot set to
/www/httpd/html/UserName. So far I've tried this:
UseCanonicalName Off
if($HTTP_HOST =~ s/(?:www\.)?(.*)\.domain\.com//g)
{
$VirtualDocumentRoot = "/www/httpd/html/$1";
}
else
{
$VirtualDocumentRoot = '/www/httpd/html/%-3';
}
1;
The second $VirtualDocumentRoot line works fine, but I NEED to be able to
get the first line to work instead, using if possible.
Any guesses?
Jonathan
