Time-Zones

--=-tddmhqocwAaG82+uvj2a
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi,

i'm using Debian Linux on my notebook. I've set up the system to use the
UTC because better filesystem syncronisation. To get the local time on
the console i added "export TZ=3DEurope/Berlin" to ~/.bash_profile. But i
dont know how to configure gnome to translate the UTC to the local time;
can anyone help?

thx,

thorsten
,,,,,
( o ~ )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~.oooO~~(_)~~Oooo.~~~

--=-tddmhqocwAaG82+uvj2a
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBB7iIefqTT+g1FweURAjzCAJ9bE40l5XmFmaO1D6/6s5RNSLheDgCa AgRF
Nc5DUhhgEZ61ClY2Mp+Vgb0=
=5/mI
-----END PGP SIGNATURE-----

--=-tddmhqocwAaG82+uvj2a--

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Cannot load mysql extension; don"t want to disturb mysql installed

Platform: Redhat Linux Enterprise WS 3
PHP installed: 4.3.2
MySQL installed: 4.0.21
Apache installed: 2.0.46

When setting up PhpMyAdmin today, I got the error:
Cannot load mysql extension,
Please check PHP configuration

My phpinfo() shows:
'with-mysql=shared,/usr' (yes, the comma is not a mistake)
- This looks like a glitch; should I fix, and if so where?

Mysql.so was found in:
/usr/lib/php4/

My php.ini has been editted to read:
extension=mysql.so
....and I also tried:
extension="/usr/lib/php4/mysql.so"

Any clues on remedying this problem, without upgrading MySQL? I have read
the problem is solved by installing a PHP-MySQL package, but when I
attempted to do so via up2date, I was notified that a dependency was
required for a MySQL-client. But Mysql 4.0.21 is already installed and
running.

Any clues out there?

Thanks,
Eve

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Cannot load mysql extension; don"t want to disturb mysql installed

As an addendum to this,
extension=msyql.so
....is enabled in /etc/php.d/mysql.ini, which the php config states from
which Redhat loads its extensions.

I've also tried:
extension="/usr/lib/php4/mysql.so"
....to no avail.

- Eve

-----Original Message-----
From: linux-newbie-owner@vger.kernel.org
[mailto:linux-newbie-owner@vger.kernel.org] On Behalf Of Eve Atley
Sent: Thursday, January 20, 2005 1:33 PM
To: 'Linux Newbie'
Subject: Cannot load mysql extension; don't want to disturb mysql installed



Platform: Redhat Linux Enterprise WS 3
PHP installed: 4.3.2
MySQL installed: 4.0.21
Apache installed: 2.0.46

When setting up PhpMyAdmin today, I got the error:
Cannot load mysql extension,
Please check PHP configuration

My phpinfo() shows:
'with-mysql=shared,/usr' (yes, the comma is not a mistake)
- This looks like a glitch; should I fix, and if so where?

Mysql.so was found in:
/usr/lib/php4/

My php.ini has been editted to read:
extension=mysql.so
....and I also tried:
extension="/usr/lib/php4/mysql.so"

Any clues on remedying this problem, without upgrading MySQL? I have read
the problem is solved by installing a PHP-MySQL package, but when I
attempted to do so via up2date, I was notified that a dependency was
required for a MySQL-client. But Mysql 4.0.21 is already installed and
running.

Any clues out there?

Thanks,
Eve

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Time-Zones

Thorsten Alge wrote:

>Hi,
>
>i'm using Debian Linux on my notebook. I've set up the system to use the
>UTC because better filesystem syncronisation. To get the local time on
>the console i added "export TZ=Europe/Berlin" to ~/.bash_profile. But i
>dont know how to configure gnome to translate the UTC to the local time;
>can anyone help?
>
>thx,
>
>thorsten
> ,,,,,
> ( o ~ )
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~.oooO~~(_)~~Oooo.~~~
>
>
You could write a script, but I'm not that familiar with Gnome, so I
cannot tell you how to implement it.

Jeremy Abbott
jkbullfrog@comcast.net

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Translating IP tables

I'm wanting to set up to allow port 23 to be accepted via the internet in my
Linux box running RedHat Linux Enterprise Workstation. I did some research
and have an output pasted below; am I truly allowing input/output from the
internet?

What I truly am attempting to do is telnet to port 5201 in order to allow
for VNC, but it appears I can not telnet on port 23 either (telnetting to
the machine on port 5201 should bring back an rfb: prompt, but connection is
refused on both 5201 and 23); so, my first guess is that I need to allow
port 23. Can someone assist me in cleaning up?

Thanks,
Eve


Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:telnet

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT ipv6-crypt-- anywhere anywhere
ACCEPT ipv6-auth-- anywhere anywhere
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp
dpt:smtp
ACCEPT tcp -- anywhere anywhere state NEW tcp
dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp
dpt:ftp
ACCEPT tcp -- anywhere anywhere state NEW tcp
dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp
dpt:7886
ACCEPT tcp -- anywhere anywhere state NEW tcp
dpt:webcache
ACCEPT tcp -- anywhere anywhere state NEW tcp
dpt:cvspserver
REJECT all -- anywhere anywhere reject-with
icmp-host-prohibited

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Translating IP tables

At 11:48 AM 2/1/2005 -0500, Eve Atley wrote:


>I'm wanting to set up to allow port 23 to be accepted via the internet in my
>Linux box running RedHat Linux Enterprise Workstation. I did some research
>and have an output pasted below; am I truly allowing input/output from the
>internet?
>
>What I truly am attempting to do is telnet to port 5201 in order to allow
>for VNC, but it appears I can not telnet on port 23 either (telnetting to
>the machine on port 5201 should bring back an rfb: prompt, but connection is
>refused on both 5201 and 23); so, my first guess is that I need to allow
>port 23. Can someone assist me in cleaning up?

I won't belabor this point, but I do feel an obligation to mention, at
least in passing, that accepting telnet (port 23) input on a server
connected to the Internet is a major security risk. I assume you are a
grownup and cam make your own decisions about balancing risks and benefits,
but my conscience won't let me troubleshoot telnet problems without at
least mentioning their riskiness.

In any case, getting port 5201 working DOES NOT require you first to get
port 23 working. Although you can use the telnet *client* to test other
ports, as you seem to be doing here, that sort of test works just fine
without a functioning telnet *server* on the target host.

Below, I comment on your firewall rulesets in specific and identify the
likely problem ... but not the solution, because I do not know how RH
generates its rulesets. If you were able to modify the INPUT chain, though,
I guess you do, so you can use that knowledge to modify the
RH-Firewall-1-INPUT so it ACCEPTs port 5201.

>Thanks,
>Eve
>
>
>Chain INPUT (policy ACCEPT)
>target prot opt source destination
>RH-Firewall-1-INPUT all -- anywhere anywhere
>ACCEPT tcp -- anywhere anywhere tcp dpt:telnet

Because the first rule directs all traffic to the RH-Firewall-1-INPUT
chain, subsequent rules have no effect. So the second, ACCEPT rule is
irrelevant.

>Chain FORWARD (policy ACCEPT)
>target prot opt source destination
>RH-Firewall-1-INPUT all -- anywhere anywhere
>
>Chain OUTPUT (policy ACCEPT)
>target prot opt source destination
>
>Chain RH-Firewall-1-INPUT (2 references)
>target prot opt source destination
>ACCEPT all -- anywhere anywhere
>ACCEPT icmp -- anywhere anywhere icmp any
>ACCEPT ipv6-crypt-- anywhere anywhere
>ACCEPT ipv6-auth-- anywhere anywhere
>ACCEPT all -- anywhere anywhere state
>RELATED,ESTABLISHED
>ACCEPT tcp -- anywhere anywhere state NEW tcp
>dpt:smtp
>ACCEPT tcp -- anywhere anywhere state NEW tcp
>dpt:http
>ACCEPT tcp -- anywhere anywhere state NEW tcp
>dpt:ftp
>ACCEPT tcp -- anywhere anywhere state NEW tcp
>dpt:ssh
>ACCEPT tcp -- anywhere anywhere state NEW tcp
>dpt:7886
>ACCEPT tcp -- anywhere anywhere state NEW tcp
>dpt:webcache
>ACCEPT tcp -- anywhere anywhere state NEW tcp
>dpt:cvspserver
>REJECT all -- anywhere anywhere reject-with
>icmp-host-prohibited

This chain is, probably, the source of your problem. (In saying this, I am
making a guess about its first entry; see next paragraph.) It needs ACCEPT
rules for ports 5201 and (if you *really* want telnet itself) 23. And, for
that matter, for ANY service that you wish to run on this host. (They need
to have the same form as the rules currently present for smtp, heep, and so
forth.) Without such rules, the traffic drops down to the last rule in this
chain, which causes it to be REJECTed.

An aside: when listing rulesets, it is better to use the -nvL flags. The
listings you provided here are incomplete ... probably not in ways that
matter to your actual problem, but in ways that do often matter to ruleset
troubleshooting ... for example, the first rule in the chain is
incomprehensible as written in this output (it must have some flags set
that are not listed in this format, or it would simply ACCEPT all traffic).

If my guess about this first rule is mistaken, then your iptables rules are
NOT the source of the problem, and you need to tell us more about the VNC
server installation itself. You are correct that it should reply to a
telnet connection with a prompt that begins with "RFB" (on my VNC host, it
is "RFB 003.003"). Make sure that the vncserver is actually listening on
port 5201 ("netstat -ln" is one way).




--
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.4 - Release Date: 1/25/2005


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Translating IP tables

Thanks, Ray, for your info so far. Here's what I've discerned...

1. Netstat does show 5901 is running (with much snipped)...
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 0.0.0.0:5801 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN


2. I flushed the nasty port 23 away from the iptables, and attempted to add
5901 using the following command:
iptables -A RH-Firewall-1-INPUT -m state --state NEW -p tcp
--destination-port 5901 -j ACCEPT

3. Now 'iptables -nvL' gives me this:

Chain RH-Firewall-1-INPUT (2 references)
pkts bytes target prot opt in out source
destination
2964 320K ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 255
0 0 ACCEPT esp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT ah -- * * 0.0.0.0/0
0.0.0.0/0
44 34271 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:25
1 48 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:21
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:7886
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:8080
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:2401
172 29486 REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-prohibited
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp dpt:5901


4. When I try to telnet to the machine's IP using port 5901, it still
indicates Connection Failed, despite it being set up like everything else
that works.

Final thought: perhaps it makes a difference that it follows the REJECT?


Thanks again,
Eve


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

RE: Translating IP tables

At 06:54 PM 2/1/2005 -0500, Eve Atley wrote:
[skipping a lot]
>2. I flushed the nasty port 23 away from the iptables, and attempted to add
>5901 using the following command:
> iptables -A RH-Firewall-1-INPUT -m state --state NEW -p tcp
>--destination-port 5901 -j ACCEPT
>
>3. Now 'iptables -nvL' gives me this:
[...]
> 172 29486 REJECT all -- * * 0.0.0.0/0
>0.0.0.0/0 reject-with icmp-host-prohibited
> 0 0 ACCEPT tcp -- * * 0.0.0.0/0
>0.0.0.0/0 state NEW tcp dpt:5901
>
>
>4. When I try to telnet to the machine's IP using port 5901, it still
>indicates Connection Failed, despite it being set up like everything else
>that works.
>
>Final thought: perhaps it makes a difference that it follows the REJECT?


Yes, you got it on the first try. Chains work from top to bottom; a packet
goes down the chain only until it finds a matching rule; then it follows
that rule without ever looking at subsequent rules (with a few exceptions
that are incidental in this context).

You need to do one of two things:

1. Find the script that creates the chain and add your new rule to it ahead
of the final REJECT rule. Where and what that script is is RH specific, and
I don't know Red Hat, so you need to find it on your own or get help from
someone else.

2. Instead of adding the rule ("iptables -A"), insert the same rule
("iptables -I" or maybe "iptables -I 1" ... I forget if -I without a number
defaults to position 1), so it will go at the start of the chain rather
than the end.




--
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.4 - Release Date: 1/25/2005


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs