SEO

Hi there,

I was wondering if it's possible to Clear MySQL's History Remotely.

Considering that you only have root access to the database but no
access to the linux box.

I found something in Goggle to do this, but you need to have access to
the linux box:

cat /dev/null > ~/.mysql_history

How can you do this remotely with only root access to the database and
not to the linux box?

> I was wondering if it's possible to Clear MySQL's History Remotely.
>
> Considering that you only have root access to the database but no
> access to the linux box.

I think (and hope) you cannot do such a thing.



Regards
Dimitre

On 23 Sep 2006 08:31:32 -0700, mdavila78 wrote:
> Hi there,
>
> I was wondering if it's possible to Clear MySQL's History Remotely.
>
> Considering that you only have root access to the database but no
> access to the linux box.
>
> I found something in Goggle to do this, but you need to have access to
> the linux box:
>
> cat /dev/null > ~/.mysql_history
>
> How can you do this remotely with only root access to the database and
> not to the linux box?

The .mysql_history file is on the machine that runs the client, not the
server. So, if you're running the client on your machine and connecting
to a remote database server, you should look on YOUR machine for the
history file. A machine which, I hope, you should have access to. If
you're making an insane kind of telnet connection to a CLI on another
machine to (from there) issue a connect to reach the database, you're
out of luck. (I cannot rightly understand *why* someone would set a
sytem up that way, but it's possible. If that's the case, I recommend
finding a different provider -- you'll share history with every other
user of the same CLI. Well, I suppose you could try setting your pager
to "cat /dev/null > ~/.mysql_history" and run "SELECT 'FOO'", then set
pager back to something else, but...)

--
_ o
|/)

mdavila78 wrote:
> I was wondering if it's possible to Clear MySQL's History Remotely.

Hmm. Trying to cover your tracks? :-)

Note that the .mysql_history is a history of commands run by the client
on that host. So if you have no shell access on that host, SQL
statements you run won't be recorded in the .mysql_history file on that
host. They'll be recorded in the .mysql_history file on your client host.

Anyway, I agree with Dimitre, if you have no shell access on the
database server host, you have no privilege to modify files there.
MySQL cannot, and should not, grant that access.

If you have FTP access, you could upload a zero-length file, copying it
over a file for which you have write privileges.

MySQL has other logs which may be recording all queries against the
server, regardless of the origin client that executed the query. See
http://dev.mysql.com/doc/refman/5.0/en/query-log.html But this is also
inaccessible if you don't have shell access on the server host.

Regards,
Bill K.

Peter H. Coffin wrote:
> If you're making an insane kind of telnet connection to a CLI on another
> machine to (from there) issue a connect to reach the database, you're
> out of luck. (I cannot rightly understand *why* someone would set a
> sytem up that way, but it's possible.

This is not unusual, I have done it frequently. For example, if you're
trying to reach a host behind a firewall, and telnet (or more likely
ssh) is allowed through the firewall, but MySQL's port 3306 isn't.

Another reason is bandwidth: the host to which you telnet is connected
to the database server by a nice fast network. The two hosts could be
in the same data center, connected by a gigabit switched network, for
instance. But suppose your desktop PC is connected to that network via
a much slower link. You may be in another building, or even halfway
around the world. Data loads or data dumps would be very quick between
the two proximal hosts, but very slow if you have to transfer volumes of
data that way to/from your PC. You might also be sharing the slow link
with other users, and such use of bandwidth would be interruptive to them.

Regards,
Bill K.

On Sat, 23 Sep 2006 11:22:07 -0700, Bill Karwin wrote:

> Peter H. Coffin wrote:
>
>> If you're making an insane kind of telnet connection to a CLI
>> on another machine to (from there) issue a connect to reach the
>> database, you're out of luck. (I cannot rightly understand *why*
>> someone would set a sytem up that way, but it's possible.
>
> This is not unusual, I have done it frequently. For example, if you're
> trying to reach a host behind a firewall, and telnet (or more likely
> ssh) is allowed through the firewall, but MySQL's port 3306 isn't.
>
> Another reason is bandwidth: the host to which you telnet is connected
> to the database server by a nice fast network. The two hosts could be
> in the same data center, connected by a gigabit switched network, for
> instance. But suppose your desktop PC is connected to that network via
> a much slower link. You may be in another building, or even halfway
> around the world. Data loads or data dumps would be very quick between
> the two proximal hosts, but very slow if you have to transfer volumes
> of data that way to/from your PC. You might also be sharing the slow
> link with other users, and such use of bandwidth would be interruptive
> to them.

*shrug* I can see the use you're talking about for remote DBA work, but
the poster in question was supposing no access to the machine he was
connecting from. I can't see how any of the advantages you're describing
would be of benefit without access to the machine the CLI is running
on. There's no access to locally-stored large files to be loaded or
extracted from the database host. That is, you gotta have access to
files to get any use out of a LOAD DATA INFILE...

--
62. I will design fortress hallways with no alcoves or protruding structural
supports which intruders could use for cover in a firefight.
--Peter Anspach's list of things to do as an Evil Overlord

>I was wondering if it's possible to Clear MySQL's History Remotely.

Whose MySQL history? Every user on every machine that uses the
'mysql' command-line client has their own history in their own
home directory on their own machine.

>Considering that you only have root access to the database but no
>access to the linux box.
>
>I found something in Goggle to do this, but you need to have access to
>the linux box:
>
>cat /dev/null > ~/.mysql_history

If you do not have access to the linux box, how did anything of
yours get INTO that file in the first place?

>How can you do this remotely with only root access to the database and
>not to the linux box?

You don't. But you can't put anything *IN* the file either, so what is
it you are trying to erase?

Peter H. Coffin wrote:
> *shrug* I can see the use you're talking about for remote DBA work, but
> the poster in question was supposing no access to the machine he was
> connecting from.

I know it's not relevant to the OP's situation, I was just pointing out
that such a situation is not necessarily "crazy" as you termed it.

> That is, you gotta have access to
> files to get any use out of a LOAD DATA INFILE...

Well, there's "LOAD DATA LOCAL INFILE ..." which loads a file on the
client host and sends it over the network connection.

In the other direction, output of mysqldump is sent over the network to
be saved on the client side.

Regards,
Bill K.