Isn't this intended behaviour?

http://dev.mysql.com/doc/refman/5.0/en/server-options.html#option_mysqld_skip-networking

skip-networking prevents network access and forces the use of a pipe.

There may be an issue if root could still connect. CC'ing maintainer.

CC: (none) => alien, eeeemail

Hi, 
Yes maybe, I'm new with mysql so I maybe wrong, but the client and the server are on localhost.
I had to uncomment the option to use mysql workbench and spent a few hours to discover why it didn't work.
Or is this bug related to mysql workbench package ? because without changing the my.cnf any connection is impossible, which seems not really desirable.  

Regards
antonio

In mysql-workbench choose Database => Manage connections and under connection method, change it to Local Socket/Pipe

If skip-networking is uncommented, choosing Local Socket/Pipe doesn't work either :
Connecting to MySQL server localhost...
Can't connect to MySQL server on '127.0.0.1' (111)

I also tried with the actual IP address of my computer :
Connecting to MySQL server localhost...
Can't connect to MySQL server on '10.0.2.15' (111)

Tried also on another mageia installation, same problem.

You need to restart mysqld after you make changes in my.cnf

Tested local connection from mysql-workbench here and it is fine.

I know, that's how it worked after I comment "skip-networking" in my.cnf, if you read my post.

You didn't mention in your previous posts. If you read your posts ;)

Un-comment skip-networking, so it doesn't expose your mysqld to the network.

# systemctl restart mysqld.service

Configure mysql-workbench to use localhost and connection method local socket.

Created attachment 3470 [details]
mysql-workbench screen cap 1

Created attachment 3471 [details]
mysql-workbench screen cap 2

Please give the output of

# systemctl status mysqld.service

Created attachment 3472 [details]
mysql-workbench screen cap 3 (after option comment)

Created attachment 3473 [details]
mysql-workbench screen cap 4 (enter root password )

Created attachment 3474 [details]
mysql-workbench screen cap 5 (success)

I reply to your post 7 and comment my screen captures:
 
Sorry not to have mentioned I restarted mysqld, I thought it was obvious I restarted mysqld just because it worked after the modification.

I already tried what you're suggesting, as my comment #4, but let me redo the things step by step with your instructions :
1. Un-comment skip-networking :

# cat /etc/my.cnf |grep skip-net
skip-networking
#
(done)

2. restart mysqld :
# systemctl restart mysqld.service

(no output)

3. configure mysql-workbench to use localhost and connection method local socket :

mysql-workbench screen cap 1
mysql-workbench screen cap 2

=> failed 

Now, I comment  skip-networking
# cat /etc/my.cnf |grep skip-net
# skip-networking
#

restart mysqld :
# systemctl restart mysqld.service

(no output)

configure mysql-workbench to use localhost and connection method local socket :
mysql-workbench screen cap 3
I'm prompted to enter the root password 
mysql-workbench screen cap 4
after ok :
mysql-workbench screen cap 5

=> success !


The command "systemctl restart mysqld.service" doesn't give any output on my system. If it gives something on yours, maybe we're not running the same version.

mariadb packages installed :
# rpm -qa|grep maria
mariadb-common-5.5.25-2.5.mga2
mariadb-core-5.5.25-2.5.mga2
lib64mariadb-embedded18-5.5.25-2.5.mga2
mariadb-common-core-5.5.25-2.5.mga2
mariadb-5.5.25-2.5.mga2
mariadb-extra-5.5.25-2.5.mga2
mariadb-client-5.5.25-2.5.mga2
lib64mariadb18-5.5.25-2.5.mga2


# uname -a
Linux archipel 3.4.24-desktop-3.mga2 #1 SMP Sat Jan 5 02:42:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

i thought there was a bug in myqslworkbench, where it always tries to use networking (there was a different bug report of this quite a while ago), i think in the end, the configuration was a problem somewhere.

to make sure, please use wireshark and try to connect to local socket, and notice that 3306 will still be tried by mysql-connect.

Hi,
I don't know wireshark and I'm afraid trying to connect locat socket is beyond my competence...

wireshark is a program that listens to network traffic.

you just start wireshark and click on capture, choose the 'lo' device to capture

then start mysql-connect (configured to use local socket).

you will notice it will connect to 127.0.0.1 on port 3306. which means it's trying to connect to network instead of local socket.

if you could test this, that would help.

thanks in advance.

Right, it seems what is happening is exactly what you said.
I (re-)created a new server instance with a socket pipe, opened wireshark as a super-user and started capture 'lo'.
Then I opened the server instance and had the attached screen capture.
It's then a bug with mysql-workbench ?

Created attachment 3487 [details]
wireshark after server instance open

if you configured mysql-workbench to use socket and not network; then yes, this is a mysql-workbench bug.

however, iirc from the old bug, the reporter then said that there was some specific configuration that needed to be done... but, i can be wrong.

see #5146

Yes, it's the same bug as reported #5146 as far as I understand.
However, it's said was corrected in rpm version mysql-workbench-5.2.36-2 
I'm using mysql-workbench-5.2.36-2.1.mga2 64bits and it's still there.

It's supposed to be fixed in cauldron, but I don't have it right now so I can't test it.

Just to make sure, I tested mysql-workbench-5.2.36-2 64bits with skip-networking enabled and it doesn't work.
So maybe there's a difference between 32b and 64b versions.

Then, what should I do ?

connect using 127.0.0.1? or maybe try to file a bug upstream? is there a maintainer for mysql-workbench? iinm, not...

Well, if it just me, I'm using mysql-workbench in a dev environment in a virtualbox, so I can disable skip-networking I don't think there will be any potential breach in my network security.
I just thought that would be good if this could be solved for the other people that wanted to use the software.
Many thanks for your attention.

I'm getting the same issue, also on x86_64. I can't connect to the database using mysql-workbench or Navicat from localhost nor from a remote host. mysqld is running and I can access it through mysql, mysqlshow etc. I'm not at all experienced with MySQL from the command line. 

Is it definitely port 3306? There doesn't seem to be a way of getting basic information out of MariaDB like port numbers etc. Again I'm not experienced in network admin but neither lsof nor netstat show anything using port 3306.

CC: (none) => osavill

I removed MariaDB and replaced it with MySQL 5 RPMs from the MySQL site and it all works great. Also port 3306 is now showing up in the output from netstat. This strongly suggests that MariaDB is either using some other port / transport mechanism or is currently just broken.

as has been mentioned hundreds of times before, networking is disabled by default in Mageia for security reasons. connect using the local socket instead. except that i heard that if you connect with local socket that it tries to connect to ip anyway. but that is a mysql-workbench bug.

I'm sorry if I'm a bit dense Al13n, I'm just a lowly web developer, but what does "networking is disabled" mean? With "real" MySQL I have to connect using 127.0.0.1 rather than localhost is this because networking is disabled? How do I re-enable networking?

I did try local socket in mysql-workbench but, as you mention, that doesn't work. I tend to use Navicat but I don't think that does local socket. I'm not advanced enough to use MySQL in command line mode.

no, i'm sorry for being so short.

but: the problem isn't mysql or mariadb.

first of all, there's two ways to connect to mysql (in general and from mysql-workbench):

 - via "local unix socket"
 - via networking (eg: localhost or 127.0.0.1 or some remote server)


of course, local unix socket only works if the mysql server is on the local machine.

for security reasons, we ship mariadb with networking disabled (config file does that; there's a skip-networking in my.cnf (MySQL doesn't do this)).

but, mysql-workbench should be able to connect to it via "local unix socket".

the things is, in the past there might be a bug which made mysql-workbench not work when you select local unix socket... (it seemed to connect to 127.0.0.1 anyway). (or at least, it was reported to me like that).


Sadly, because you installed 5.6, you can't go back to mariadb 5.5 anymore (unless if you uninstall it and remove your databases) and mariadb 10.0 isn't stable yet.

Thirdly, be advised that MySQL 5.6 and 5.5 has serious AND exploitable security issues which have been public since their last 2 releases and still are unfixed.

i hope i made everything perfectly clear here.

this bug report is about mysql-workbench still using networking when you configure it to use "local unix socket" ...


i'm the mariadb maintainer and i don't use mysql-workbench, nor could care less about it. this may sound harsh, but i don't want to be held responsible for a bug that's not mine...

Thanks for the changes Al13n.
I would then suggest to give notice at the installation of mariadb that network connection will not work by default (and give solution), because it seems to be the default connection method.
Regards

Thanks for the clarification Al13n. I'm not too worried at going back to Maria right now as it was more important to get a working web dev environment. But when MariaDB 10 hits the repositories it's not a great problem to wipe the current databases and start fresh if mysql_upgrade won't work. And at least I've learnt a few things :-)

@antonio: actually it already does... and Mandrake/Mandriva/Mageia have always had skip-networking as default...

@owen: ic, i'm not saying it might not work, (quite some mysql-5.6 features were already in mariadb-5.5), but i just cannot give guarantees that you can actually move back from 5.6 to 5.5 (in general, it likely will only fail if you're using mysql-5.6 specific features; which i can't really imagine people will do these days)

I'm testing on my MGA 3 setup, currently Beta 4. 

Really sorry, but I still can't connect to the MariDB server using networking. What did I miss? I've commented out the skip-networking line in /etc/my.cnf but nothing seems to be able to connect to the server over a network.

if you want to connect to networking, check this:

[]# netstat -lntop

and check for mysqld, this is to see if it's actually listening on that port.

then check firewall, to see if you actually get on it.

make sure you can connect using the mysql client:

mysql -h 127.0.0.1 -u root -p

let us know how things go...

Hi Ali3n, looks like MariaDB is not listening, the output to netstat -lntop just shows one line:
tcp        0      0 :::80                       :::*                        LISTEN      1667/httpd          off (0.00/0/0)

maybe you did a typo in the configuration. try the following and see if it gives you a hint on what went wrong...

[ ]# systemctl status mysqld.service

This is a vanilla MGA 3 Beta 4 install plus updates...

$ ps -ae | grep mysql
 2530 ?        00:00:03 mysqld

$ systemctl status mysqld.service
mysqld.service
          Loaded: error (Reason: No such file or directory)
          Active: inactive (dead)

# systemctl stop mysqld.service
Failed to issue method call: Unit mysqld.service not loaded.

# systemctl start mysqld.service
Failed to issue method call: Unit mysqld.service failed to load: No such file or directory. See system logs and 'systemctl status mysqld.service' for details.

# cd /var/log/mysqld
# ls
# 

$ mysql -h 127.0.0.1 -u root -p
Enter password: 
ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)

$ mysql -h localhost -u root -p
Enter password: 
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

$ ls /var/lib/mysql/
mysql/  test/

$ ls /var/lib/mysql/mysql/
$

$ ls /var/lib/mysql/test/
$

you have no mysqld.service.... wtf???

did you run mysqld yourself?


in any case:

[ ]# rpm -q -a | grep mysql

> did you run mysqld yourself?
No, it's lauched during boot

$ rpm -qa | grep -i mysql
lib64mysqlcppconn6-1.1.1-2.mga3
mysql-workbench-5.2.45-2.mga3
qt4-database-plugin-mysql-4.8.4-7.mga3


# urpmi mysql
...

# systemctl stop mysqld.service
# systemctl start mysqld.service
# systemctl status mysqld.service
mysqld.service - MySQL database server
          Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
          Active: active (running) since Tue, 2013-04-02 20:07:16 BST; 2s ago
         Process: 8253 ExecStartPost=/usr/sbin/mysqld-wait-ready $MAINPID (code=exited, status=0/SUCCESS)
         Process: 7908 ExecStart=/usr/bin/mysqld_safe --nowatch (code=exited, status=0/SUCCESS)
         Process: 7833 ExecStartPre=/usr/sbin/mysqld-prepare-db-dir (code=exited, status=0/SUCCESS)
        Main PID: 8252 (mysqld)
          CGroup: name=systemd:/system/mysqld.service
                  â 8252 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mysqld/mysqld.log --pi...

Apr 02 20:07:14 localhost mysqld-prepare-db-dir[7833]: The latest information about MariaDB is available at http://mariadb.org/.
Apr 02 20:07:14 localhost mysqld-prepare-db-dir[7833]: You can find additional information about the MySQL part at:
Apr 02 20:07:14 localhost mysqld-prepare-db-dir[7833]: http://dev.mysql.com
Apr 02 20:07:14 localhost mysqld-prepare-db-dir[7833]: Support MariaDB development by buying support/new features from
Apr 02 20:07:14 localhost mysqld-prepare-db-dir[7833]: Monty Program Ab. You can contact us about this at sales@montyprogram.com.
Apr 02 20:07:14 localhost mysqld-prepare-db-dir[7833]: Alternatively consider joining our community based development effort:
Apr 02 20:07:14 localhost mysqld-prepare-db-dir[7833]: http://kb.askmonty.org/en/contributing-to-the-mariadb-project/
Apr 02 20:07:14 localhost mysqld_safe[7908]: 130402 20:07:14 mysqld_safe Logging to '/var/log/mysqld/mysqld.log'.
Apr 02 20:07:14 localhost mysqld_safe[7908]: 130402 20:07:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Apr 02 20:07:16 localhost systemd[1]: Started MySQL database server.

# netstat -lntop
tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN      8252/mysqld         off (0.00/0/0)
tcp        0      0 :::80                       :::*                        LISTEN      1920/httpd          off (0.00/0/0)

and yes, I can now connect to it.


Thanks once again.

OK, I am joining this.
I can manually connect to the server
mysql -u root -p

I see some differences to mga1. There when you want to connect, mysql-workbench is asking for a password, in mga3 it isn't.

I am increasing the priority and severity because the package is no usable.

Priority: Normal => High
CC: (none) => thomas
Severity: normal => critical

hi Thomas,
it's just what I'm trying to say...
In the current situation, you install the workbench package and bam ! it just doesn't work, you can't create the database objects until you understand that there is a bug on the local socket pipe connection AND network connection is disabled by default, so the only solution is to disable skip-networking (with security concerns).

Initially, this bug report was badly named as a database connection bug (my fault...), but finally the problem is with the mysql-workbench package, so it was renamed.

Antonio:
>Initially, this bug report was badly named as a database connection bug>

Thanks for the hint. I didn't expect the requirement to comment out "skip-network connection" in /etc/my.cf for a local connection.
For me, the connection works now, using tcp or pipe.
Antonio, please try this, if it works we may close this bug?

Priority: High => Normal
Severity: critical => major

IIRC, the bug is really that when you select socket, that it tries network connection anyway...

Thomas,
If you see my comment #14, I already tried it and confirmed with wireshark that socket connection tries network anyway.

It seems that it's the same bug as 5146:
https://bugs.mageia.org/show_bug.cgi?id=5146

Unfortunately I can't test it again right now because I had to install the last version of mysql-workbench from tar sources, there is a bug in mageia current version with the table comments length (http://bugs.mysql.com/bug.php?id=61626), corrected in version 5.2.37.
My version is now 5.2.46
The bizarre thing is that I have the same problem on version 5.2.46 : it uses the network anyway if I try to start the server instance using a local socket (see scrren capture from wireshark below)
with error message :
Connecting to MySQL server socket3...
Can't connect to MySQL server on 'localhost' (111)
(socket3 is the name i gave to the server instance)

Created attachment 3974 [details]
wireshark capture using local socket w/ version 5.2.46

Antonio:
So why not manually put a root password in and then commenting out the line in the config file that prevents from connecting from the network. The idea is not being able to connect from the network until mysql is secured with a password.

Why a install from a tar and not just locally build a newer rpm so you can uninstall it easily or upgrade it? :)

(In reply to AL13N from comment #43)
> IIRC, the bug is really that when you select socket, that it tries network
> connection anyway...

This may be on purpose so nobody can connect accidentally before the database is secured. (As me stumping over it)

better check to be sure it actually doesn't use network after you configured it :-)

(In reply to Thomas Spuhler from comment #46)
> Antonio:
> So why not manually put a root password in and then commenting out the line
> in the config file that prevents from connecting from the network. The idea
> is not being able to connect from the network until mysql is secured with a
> password.

I'm not sure I understand your suggestion well, but if I try to create the server instance and skip-networking is commented, I'm not prompted to enter a password, with local socket or standard tcp/ip, it fails at the database connection test.
If skip-networking is disabled, I'm prompted to enter the root (user for connection) password, and it works. 
As far as I understand, it's because the db test connection always uses network and it fails if skip-networking is enabled.

But is the socket connection mode not supposed not to use the tcp/ip, so skip-networking commented out or not should have no impact ?
     
> 
> Why a install from a tar and not just locally build a newer rpm so you can
> uninstall it easily or upgrade it? :)

Yes, you're right, I should have done this :)

the way i read thomas' comments, is that he says that if in the configuration in workbench, you enter credentials somewhere, that the socket option will be enabled, otherwise it isn't. and he thinks this is a security option to make sure you've secured mysqld before accepting the socket?

it sounds weird to me, but who knows...


in any case, the skip-networking is disabled by default and on local machines it's better to use local socket. (and there should be no need to turn this off just for the local service.

Assigning to mysql-workbench maintainer.

Summary: mysql-workbench in Mageia 2 can't connect to a local database via socket. It always tries to connect via IP to 127.0.0.1 instead of socket on localhost. This makes it impossible to connect to mariadb until you remove the skip-networking option in my.cnf. 

Expected behaviour: when trying to connect to localhost via *socket*, mysql-workbench should. This might be an upstream bug that has been fixed since, since Mageia 3 doesn't have this issue.

Thanks!

Keywords: (none) => Triaged
CC: (none) => stormi
Assignee: bugsquad => juan.baptiste

(In reply to AL13N from comment #50)
> the way i read thomas' comments, is that he says that if in the
> configuration in workbench, you enter credentials somewhere, that the socket
> option will be enabled, otherwise it isn't. and he thinks this is a security
> option to make sure you've secured mysqld before accepting the socket?
> 
> it sounds weird to me, but who knows...
> 
> 
> in any case, the skip-networking is disabled by default and on local
> machines it's better to use local socket. (and there should be no need to
> turn this off just for the local service.

Are we trying to capture a ghost?
This statement is wrong:
skip-networking is disabled by default. It's enabled for security reasons.

What needs to be done is using a shell, add a rootpaswword and then disable skip-networking by commenting it out and restart mysqld.
This is still the case in mga 3.

(In reply to Thomas Spuhler from comment #52)
> This statement is wrong:
> skip-networking is disabled by default. It's enabled for security reasons.

I'm sure that's also what AL13N meant.

> 
> What needs to be done is using a shell, add a rootpaswword and then disable
> skip-networking by commenting it out and restart mysqld.
> This is still the case in mga 3.

Yes, this is a *workaround*. However, you can connect to mysql via a local socket, which does not require networking to be enabled in mysql. mysql-workbench proposes both network connection to 127.0.0.1 AND local socket connection but the latter appears not to work in MGA2's version of it.

Summary: mysql-workbench "Can't connect to MySQL server" => mysql-workbench can't connect to local mysql via local socket

iinm, it seemed (at least in mga2, i cannot confirm nor deny existance in mga3) that if you chose local socket connection (no networking) that it tried connecting to networking anyway)

perhaps the mysql-workbench maintainer could modify the default setting to use local socket connection. that might get rid of all these reports.

if you chose local socket connection (no networking) that it tried connecting to networking anyway)

I have never been able to login this way, if skip-networking is active, not in mga1 nor mga3. I skipped mga2

if it doesn't work, it's a mysql-workbench bug.

can you test mga3 with local socket?

if it doesn't work, can you try to find out what socket file it's trying to connect to?

maybe with strace or something?

(In reply to AL13N from comment #56)
> if it doesn't work, it's a mysql-workbench bug.
> can you test mga3 with local socket?
> if it doesn't work, can you try to find out what socket file it's trying to
> connect to?
> maybe with strace or something?

In Mageia 3, it works ok. In Mageia 2, it seems to
be ignoring the socket that's input, and tries to connect to
/var/run/uuidd/request, and when that fails falls back to
trying a tcp connection to 127.0.0.1, port 3306.

CC: (none) => davidwhodgins

maybe the mysql-workbench can be packaged with a symlink of this /var/run/uuid/request to the mysql socket? in mga2?

and what about changing the default in cauldron to use the local socket by default?

(In reply to AL13N from comment #58)
> maybe the mysql-workbench can be packaged with a symlink of this
> /var/run/uuid/request to the mysql socket? in mga2?
> 
> and what about changing the default in cauldron to use the local socket by
> default?

I just tried creating the symlink
/var/run/uuidd/request -> /var/lib/mysql/mysql.sock=
but it still fails to connect.

I installed and started uuidd. Now checking for connections ...
grep 'connect(' strace.txt
6815  connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
6815  connect(7, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
6815  connect(7, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
6815  connect(7, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
6815  connect(11, {sa_family=AF_FILE, path="/var/run/uuidd/request"}, 110) = 0
6815  connect(11, {sa_family=AF_FILE, path="/var/run/uuidd/request"}, 110) = 0
6817  connect(8, {sa_family=AF_FILE, path="/var/run/uuidd/request"}, 110) = 0
6815  connect(8, {sa_family=AF_FILE, path="/var/run/uuidd/request"}, 110) = 0
6815  connect(8, {sa_family=AF_FILE, path="/var/run/uuidd/request"}, 110) = 0
6815  connect(10, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
6815  connect(10, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)

So it simply isn't trying to connect to the specified socket.

The uuidd was just a red herring.

Why are you still trying. It's no going to work if skip-networking isn't commented out.
It seems pipe still needs the network.

(In reply to Thomas Spuhler from comment #60)
> Why are you still trying. It's no going to work if skip-networking isn't
> commented out.
> It seems pipe still needs the network.

It isn't required in Mageia 3. There is a bug in the Mageia 2
version, such that it never tries to connect to a local socket.
That's the whole point of this bug report. It should not be
required, as commenting out the skip-networking reduces
security.  My testing and comments are part of trying to
narrow down where the bug is.

(In reply to Thomas Spuhler from comment #60)
> Why are you still trying. It's no going to work if skip-networking isn't
> commented out.
> It seems pipe still needs the network.

local sockets are NOT network...

in fact the "mysql" command (client) is using socket by default, which is why it works.

but, it seems the uuid is something else entirely.

maybe it's not connecting to a socket, because no default socket path is specified?

what kind of settings are there in workbench when you select socket?

maybe the default socket needs to be specified during compile or something?

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD