the-debil

I think I may understand what you are saying – again correct me if I am wrong.

Are you saying that someone else on a shared server, could cd across. So in such circumstances, it would be another client who already has access to the shell on the same server would cd across, then ls and edit files?

Which is conceivable – but as likely as being hit by a bus in this particular circumstance. And still would not be a major security risk as the website had not been installed. Which brings me back to the process of elimination. One stage at a time… which I tried to allude to – and naturally admitted that if I had followed the link would have seen for myself that it was not a permission issue.

Long and winded affair, but what do you think the odds are of what you describe actually happening.

UKMMA

my host is 1&1 and I created db using their “MS SQL Administration”

yes I know the name servers of my actual server as I had to input these into the config file

That answers my questions really, I was doing to see what services were available on your server, with a dns look up.

As samboll has said, MySQL 4 and above.

Cheers
Dave

Absolutely – we should move on, although I do think it is useful for all people to understand that they can experiment with permissions on their server in order to try and resolve problems. I think you were right, in that it does look like a server config issue. Something I should have seen by looking at the link.

As for 777 security. The word world or all refers to the server and not the greater outside world. In order for it to be a security issue, there would need to be access above that particular directory, such as an application / script or FTP.

There are indeed millions of directories set to 777. Any security issue is confined within that directory, the issue is relative to that directory and still requires some kind of access. Password and User ID.

This issue is done to death on thousands of websites: Google: what are 777 security risks.

https://www.google.com/#hl=en&q=what+are+the+777+security+risks&aq=f&oq=&aqi=&fp=AYh9MvVRflg

Yes I should have viewed the domain, but it still is not the security risk you are claiming.

whooami

At best you would need access to something else on the server via a user ID and password – like an application. Simply having access to a directory via a browser – that is set to 777 will get you nowhere. There are millions of web directories set to 777.

whooami

Actually, it is a process of elimination, a suck it and see process. But I was advising on just reading the content of the post, not following the domain link.

As for security. World write permissions in such circumstances do not present a problem for security – unless you decide to tell everyone your FTP user id and password. Then in such circumstances the permissions setting is irrelevant.

It would only be a security issue if something in the actual application installed, permitted unauthorised or lower than owner users to write to that specific directory. Which it does not.

Now having looked at the actual server, it is clear that it isn’t a permission issue, as none of the files on there are resolving. So it’s on to server support.

UKMMA

Actually just had a look at the domain and it does appear to be a server config issue. None of the files are are displaying. I thought you were just having problems seeing the wp-admin/install.php

As samboli said, best contact support…

UKMMA

It doesn’t appear to be anything to do with your database at this stage. It looks like a permissions issue. But it could be a server config issue.

Changing the permissions on the directory and file, will quickly either confirm or eliminate the possibility of a permissions issue.

At this stage, the database is an empty database – until you actually run the install – then it is populated with the relevant tables.

whooami

Yes I do know what I’m talking about – thanks, if the folder is definitely on the server and does not have a world read and execute permission – then it will not display or work in the browser.

Even if it fails, its worth trying.

Thanks.

FTP to the server and change the permissions of the folder and file to 777.

Then see if it works.

What process did you use for creating your database?

Which hosting company are you using?

Do you know the nameservers of your actual server?

Cheers
Dave

First thing to do is to post in the correct forum:
That way, more people are likely to help you.

I personally tend to ignore posts which are in the wrong forum – because they clogg up and distract from those posts which are in the correct area.

I also assume that if people can’t understand the difference between installation and design, then they are likely to struggle with my answer – regardless of how simple I make it.

Andy…

That’s a very good decision.

BTW… from what you said about the techie guy, it is clear that running the upgrade is beyond him. It’s quite involved… best done in stages – with a series of tests. Also requires knowing shell command line. Although I have been told there is a way to do it using phpMyAdmin.

Given his complete lack of knowledge. Not sure he wold have handled this – assuming mySQL 5 is ready to go on your server:

Upgrading from MySQL 3.23 to MySQL 5, to avoid compatibility issues it is best to upgrade to MySQL 4.0 first as a stepping stone.

Bear in mind that after you have upgraded, you should use the files and directories associcated with the new version of MySQL. If, for example, you move from 3.23 to 5.0, rather than using /usr/bin/mysql you would need to use /opt/mysql-5.0/bin/mysql.

Overview

The upgrade process in outline is broadly the same across versions (file and directory paths do vary though, so take care).

1. Stop the old MySQL (edit rc.conf and reboot)
2. Backup (copy the directory)
3. Rename the data directory
4. Start the new MySQL (edit rc.conf and reboot)
5. Run the new version’s upgrade commands
6. Confirm that the database is functioning properly
7. Remove the backup

Step by step from 3.23 -> 4.0

The first thing you will need to do is backup the existing data.

Disable the existing MySQL installation. Open the /usr/local/etc/rc.conf file, and locate the following line:

mysql_enable=”YES”

Change it to read:

mysql_enable=”NO”

Reboot server. MySQL is now not currently running, so the data on disc is in a consistent state.

Copy the database directory:

cp -a /usr/local/var/lib/mysql /usr/local/var/lib/mysql.v3.backup

Move the database directory:

mv /usr/local/var/lib/mysql /usr/local/var/lib/mysql-4.0

Change /usr/local/etc/rc.conf to read:

mysql_enable=”YES”
mysql_version=”4.0″

Once you’ve made this change, reboot the server. You’ll now be running MySQL 4.0 rather than the original 3.23 version.

There are still some changes to be made to enable the system to work correctly.

Firstly you will need to upgrade the MySQL privilege table. This is achieved by typing at the shell:

/opt/mysql-4.0/bin/mysql_fix_privilege_tables <password>

Substitute your MySQL administrator’s password for <password>.

Some existing databases may also need to be upgraded to new table types. You can achieve this by using the command:

/opt/mysql-4.0/bin/mysql_convert_table_format <databasename>

Running this command for each of your databases will upgrade them to the new table format.

Once you are happy that MySQL 4 is working correctly you can remove the backed up data (unless you are moving to MySQL 5 by way of MySQL 4, in which case you may wish to keep the backups until you have completed the entire process).

rm -rf /usr/local/var/lib/mysql.v3.backup

4.1 and beyond

The upgrade from MYSQL 4.0 to MySQL 4.1 and above follows the same basic outline , just the file/directory paths vary.

E.g. /opt/mysql-4.0/bin/ becomes /opt/mysql-4.1/bin/ or /usr/local/var/lib/mysql-4.0/ becomes /usr/local/var/lib/mysql-5.0/.

So from MySQL 4.0 to MySQL 5.0:

Edit /usr/local/etc/rc.conf:

mysql_enable=”YES”

to:

mysql_enable=”NO”

Reboot:

reboot server

Backup:

cp -a /usr/local/var/lib/mysql-4.0 /usr/local/var/lib/mysql.v4.0.backup

Rename:

mv /usr/local/var/lib/mysql-4.0 /usr/local/var/lib/mysql-5.0

Edit /usr/local/etc/rc.conf:

mysql_enable=”YES”
mysql_version=”5.0″

Reboot:

rebootv server

Run upgrade command

/opt/mysql-5.0/bin/mysql_upgrade –datadir=/usr/local/var/lib/mysql-5.0 <password>

Once you are happy that MySQL 5 is working correctly:

rm -rf /usr/local/var/lib/mysql.v4.0.backup

Otto42

Totally disagree with the use of a big stick. That is completely outrageous. Is there a shortage of cod near you? – if so – use haddock.

jordy1

You do not have to be a code expert to read the upgrade instructions:

https://codex.www.ads-software.com/Upgrading_WordPress_Extended

1. Backup database
2. Back up your files
4. Deactivate plug ins

My questions to you are: Did you read this and did you actually do it?

If your answer is yes and yes… then why not just install your back up?