Installing MySQL from tar.gz Packages on Other Unix-Like Systems

http://dev.mysql.com/doc/refman/5.0/en/installing-binary.html

This section covers the installation of MySQL binary distributions that are provided for various platforms in the form of compressed tar files (files with a .tar.gz extension). See Section 2.4.3.4, 「MySQL Binaries Compiled by MySQL AB」, for a detailed list.

To obtain MySQL, see Section 2.5, 「How to Get MySQL」.

MySQL tar file binary distributions have names of the form mysql-VERSION-OS.tar.gz, where VERSION is a number (for example, 5.0.72), and OS indicates the type of operating system for which the distribution is intended (for example, pc-linux-i686).

In addition to these generic packages, we also offer binaries in platform-specific package formats for selected platforms. See Section 2.8, 「Standard MySQL Installation Using a Binary Distribution」, for more information on how to install these.

You need the following tools to install a MySQL tar file binary distribution:

• GNU gunzip to uncompress the distribution.

• A reasonable tar to unpack the distribution. GNU tar is known to work. Some operating systems come with a preinstalled version of tar that is known to have problems. For example, Mac OS X tar and Sun tar are known to have problems with long filenames. On Mac OS X, you can use the preinstalled gnutar program. On other systems with a deficient tar, you should install GNU tar first.

If you run into problems and need to file a bug report, please use the instructions in Section 1.7, 「How to Report Bugs or Problems」.

The basic commands that you must execute to install and use a MySQL binary distribution are:

shell> groupadd mysql
shell> useradd -g mysql mysql
shell> cd /usr/local
shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell> ln -s full-path-to-mysql-VERSION-OS mysql
shell> cd mysql
shell> chown -R mysql .
shell> chgrp -R mysql .
shell> scripts/mysql_install_db --user=mysql
shell> chown -R root .
shell> chown -R mysql data

Start Mysql Services (or --user=root) 
shell> bin/mysqld_safe --user=mysql &

Note

This procedure does not set up any passwords for MySQL accounts. After

following the procedure, proceed to Section 2.17, 「Post-Installation Setup and Testing」.

A more detailed version of the p

receding description for installing a binary distribution follows:

1. Add a login user and group for mysqld to run as:

   shell> groupadd mysql
   shell> useradd -g mysql mysql
   

   These commands add the mysql group and the mysql user. The syntax for useradd and groupadd may differ slightly on different versions of Unix, or they may have different names such as adduser and addgroup.

   You might want to call the user and group something else instead of mysql. If so, substitute the appropriate name in the following

   steps.

2. Pick the directory under which you want to unpack the distribution and change location into it. In the following example, we unpack the distribution under /usr/local. (The instructions, therefore, assume that you have permission to create files and directories in /usr/local. If that directory is protected, you must perform the installation as root.)

   shell> cd /usr/local
   

3. Obtain a distribution file using the instructions in Section 2.5, 「How to Get MySQL」. For a given release, binary distributions for all platforms are built from the same MySQL source distribution.

4. Unpack the distribution, which creates the installation directory. Then create a symbolic link to that directory:

   shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
   shell> ln -s full-path-to-mysql-VERSION-OS mysql
   

   The tar command creates a directory named mysql-VERSION-OS. The ln command makes a symbolic link to that directory. This lets you refer more easily to the installation directory as /usr/local/mysql.

   With GNU tar, no separate invocation of gunzip is necessary. You can replace the first line with the following alternative command to uncompress and extract the distribution:

   shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
   

5. Change location into the installation directory:

   shell> cd mysql
   

   You will find several files and subdirectories in the mysql directory. The most important for installation purposes are the bin and

   scripts subdirectories:

   • The bin directory contains cli

     ent programs and the server. You should add the full pathname of this directory to your PATH environment variable so that your shell finds the MySQL programs properly. See Section 2.21, 「Environment Variables」.

   • The scripts directory contains the mysql_install_db script used to initialize the mysql database containing the grant tables that store the server access permissions.

6. Ensure that the distribution contents are accessible to mysql. If you unpacked the distribution as mysql, no further action is required. If you unpacked the distribution as root, its contents will be owned by root. Change its ownership to mysql by executing the following commands as root in the installation directory:

   shell> chown -R mysql .
   shell> chgrp -R mysql .
   
   
   

   The first command changes the owner attribute of the files to the mysql user. The second changes the group attribute to the mysql group.

7. If you have not installed MySQL before, you must create the MySQL data directory and initialize the grant tables:

   shell> scripts/mysql_install_db --user=mysql
   

   If you run the command as root, include the --user option as shown. If you run the command while logged in as that user

   , you can omit the --user option.

   The command should create the data directory and its contents with mysql as the owner.

   After creating or updating the grant tables, you need to restart the server manually.

8. Most of the MySQL installation can be owned by root if you like. The exception is that the data directory must be owned by mysql. To accomplish this, run the following commands as root in the installation directory:

   shell> chown -R root .
   
   shell> chown -R mysql data
   
   
   

9. If you want MySQL to start automatically when you boot your machine, you can copy support-files/mysql.server to the location where your system has its startup files. More information can be found in the support-files/mysql.server script itself and in Section 2.17.2.2, 「Starting and Stopping MySQL Automatically」.

10. You can set up new accounts using the bin/mysql_setpermission script if you install the DBI and DBD::mysql Perl modules. See Section 4.6.14, 「mysql_setpermission — Interactively Set Permissions in Grant Tables」. For Perl module installation instructions, see Section 2.22, 「Perl Installation Notes」.

11. If you would like to use mysqlaccess and have the MySQL distribution in some non-standard location, you must change the location where mysqlaccess expects to find the mysql client. Edit the bin/mysqlaccess

    script at approximately line 18. Search for a line that looks like this:

    $MYSQL     = '/usr/local/bin/mysql';    # path to mysql executable
    

    Change the path to reflect the location where mysql actually is stored on your system. If you do not do this, a Broken pipe error will occur when you run mysqlaccess.

After everything has been unpacked and installed, you should test your distribution. To start the MySQL server, use the following command:

shell> bin/mysqld_safe --user=mysql &

If you run the command as root, you must use th

e --user option as shown. The value of the option is the name of the login account that you created in the first step to use for running the server. If you run the command while logged in as mysql, you can omit the --user option.

If the command fails immediately and prints mysqld ended, you can find some information in the host_name.err file in the data directory.

More information about mysqld_safe is given in Section 4.3.2, 「mysqld_safe — MySQL Server Startup Script」.

Note

The accounts that are listed in the MySQL grant tables initially have no passwords. After starting the server, you should set up passwords for them using the instructions in Section 2.17, 「Post-Installation Setup and Testing」.

Set the MySql autorun in Fedora

Install ioncube loader for atmail server test ver for linux

[ wrote from http://www.ioncube.com/loader_installation.php ]

Installation on a Unix Server

If your PHP is not threaded you need a Loader called:

ioncube_loader__.so

If your PHP is threaded you need a Loader called:

ioncube_loader___ts.so

will be 'lin' for Intel Linux, 'fre' for FreeBSD, 'sun' for Sparc Solaris, 'ope' for OpenBSD, 'dar' for OSX and 'net' for NetBSD.

will be 4.0, 4.1, 4.2 or 4.3 - i.e the first 2 digits of your PHP version.

Edit your php.ini file and for non-threaded PHP add:

zend_extension = //ioncube_loader__.so

and for threaded PHP add:

zend_extension_ts = //ioncube_loader___ts.so

Replace and with whatever is right for your system, and with the path to where the Loader is installed, e.g. /usr/local/ioncube

If there are other zend_extension entries in the php.ini file place this new entry before the existing entries.

For example, with Linux running PHP 4.1.2 and Apache 1, you might add:

zend_extension = /usr/local/ioncube/ioncube_loader_lin_4.1.so

For FreeBSD running threaded PHP 4.3.1 with Apache 2, you might add:

zend_extension_ts = /usr/local/ioncube/ioncube_loader_fre_4.3_ts.so

Linux下執行程序時發生錯誤: cannot restore segment prot after reloc: Permission denied

原來這是SELinux搞的鬼，解決辦法有兩個

1. 使用chcon 命令

示例: chcon -t texrel_shlib_t /usr/local/rsi/idl_6.1/bin/bin.linux.x86/*.so

2. 禁止掉SELinux

更改/etc/sysconfig/selinux 文件的內容為 SELINUX=disabled

Remote Access to the Fedora Linux Desktop

[ thanks copy from ]
http://www.techotopia.com/index.php/Remote_Access_to_the_Fedora_Linux_Desktop

Fedora Linux provides remote desktop access. This provides two extremely useful features. Firstly it enables you, or another person to view and interact with your desktop environment from another computer system either on the same network or over the internet. This is useful if you need to work on your computer when you are away from your desk while traveling or sitting in a coffee shop. It is also useful in situations where a co-worker or IT support technician needs access to your desktop to resolve a problem.

Secondly, in addition to providing access to your primary desktop (the one you see when you switch on your monitor every morning) it enables you to create multiple desktops and connect to them remotely.

The Fedora Linux remote desktop functionality is based on technology called Virtual Network Computing (VNC) and in this chapter we will cover the key aspects of configuring and using remote desktops with Fedora Linux. It is important to note that there are both secure and insecure ways to access a remote desktop and both approaches will be covered.

Contents [hide] 1 Activating Remote Desktop Access 2 Accessing a Remote Fedora Linux Desktop 3 Accessing a Remote Fedora Linux Desktop from a Windows System 4 Establishing a Secure Remote Desktop Session 5 Establishing a Secure Remote Desktop Session from a Windows System 6 Creating Additional Desktops

[edit] Activating Remote Desktop Access

The first step in setting up remote desktop access is to activate it and define some basic security settings. These settings are configured in the Remote Desktop Preferences dialog. To access this dialog, open the desktop System menu, select Preferences followed by Internet and Network and click on Remote Desktop. When selected the following window will appear:

In this dialog the following configuration options are available:

• Allow others to view your desktop - Activates remote desktop access for viewing purposes.

• Allow other users to control your desktop - Allows users accessing your remote desktop to control the desktop. In other words the remote user can do anything to your desktop that they want using their mouse and keyboard as if they were sitting physically at the local system.

• Ask for confirmation - When selected, this option cause a dialog to appear warning you of an attempt by a remote user to connect and prompting you to confirm or deny the connection. If you are likely to want to log in remotely you will need to turn this off since you will not be at the local system to accept your own connection.

• Require the user to enter this password - Specifies a password which must be entered by the remote user to access your desktop. It is strongly advised that you select this option and specify a password.

Finally this screen specifies the command to run on the remote system to access the desktop. Once you have configured Remote Desktop access you are ready to try connecting.

[edit] Accessing a Remote Fedora Linux Desktop

As mentioned previously there are both secure and insecure methods for accessing a remote desktop. In this section we assume that the desktop is being accessed by a remote system on the same local network where security is not a concern. See the section later in this chapter for establishing a secure connection if you are connecting from a system outside your firewall.

Having configured the remote desktop settings on the local system move to another system on your network, open a terminal window and enter the command specified in the Remote Desktop Preferences dialog, for example:

vncviewer hostname:0

where hostname is either the hostname or IP address of the remote system.

If you configured the remote system to prompt to approve a connection a dialog will appear on the remote system. Until the connection is approved the vncviewer session will wait. Once approved, or if no approval is required, VNC will prompt for the password (assuming one was defined):

If you see a message similar to the following then you will need to use the secure method of remote desktop display outlined in the next section:

main:     unable to connect to host: No route to host (113)

Otherwise, enter the password and a new screen will appear containing the desktop from the remote system. If remote desktop control was enabled you can interact with the desktop as if you were sitting at the remote screen.

This section assumed that the remote desktop was being accessed from a Linux or Unix system. Access is also possible from a Windows system.

[edit] Accessing a Remote Fedora Linux Desktop from a Windows System

In order to access a Linux remote desktop from a Windows system the first step is to install a Windows VNC client on the Windows system. There are a number of VNC packages available for Windows. In this chapter we will look at TightVNC (http://www.tightvnc.com).

Download and install TightVNC on your Windows system. Once installed, launch the TightVNC Viewer and in the resulting Connection details dialog enter the IP address or hostname of the remote system and press OK. Enter the password if one is required. The screen should load and display the remote desktop,

You may also enter the port number in the form hostname::5900 (screen 0 in VNC uses port 5900). TightVNC assumes port 5900 if none is specified but when we look at setting up additional desktops later in this chapter we will need to specify port numbers in order to connect.

[edit] Establishing a Secure Remote Desktop Session

The remote desktop configurations we have explored so far in this chapter are considered to be insecure because no encryption is used. This is acceptable when the remote connection does not extend outside of an internal network protected by a firewall. When a remote session is required over an internet connection a more secure option is needed. This achieved by tunneling the remote desktop through a secure shell (SSH) connection.

Before a secure connection is established the SSH server must be installed in the desktop to which the connection is to be established. For detailed steps on installing the SSH server on an Fedora Linux system see Configuring Fedora Linux Remote Access using SSH.

Once the SSH server is installed and active it is time to move to the other system. At the other system, log in to the remote system using the following command, which will establish the secure tunnel between the two systems:

 ssh -L 5900:localhost:5900 hostname

In the above example, hostname is either the hostname or IP address of the remote system. Log in using your account and password. The secure connection is now established and it is time to launch vncviewer so that it uses the secure tunnel. Leaving the ssh session running in the other terminal window, launch another terminal and enter the following command:

vncviewer localhost::5900

The vncviewer session will prompt for a password if one is required, and then launch the VNC viewer providing secure access to your desktop environment.

If you are connecting to the remote desktop from outside the firewall keep in mind that the IP address for the ssh connection will be the external IP address provided by your ISP, not the LAN IP address of the remote system (since this IP address is not visible to those outside the firewall). You will also need to configure your firewall to forward port 22 (for the ssh connection) to the IP address of the system running the desktop. It is not necessary to forward port 5900. Steps to perform port forwarding differ between firewalls, so refer to the documentation for your firewall, router or wireless base station for details specific to your configuration.

[edit] Establishing a Secure Remote Desktop Session from a Windows System

A similar approach is taken to establishing a secure desktop session from a Windows system. Assuming that you have a VNC client installed (as described above) the one remaining requirement is a Windows ssh client. A populuar ssh client for Windows is (PuTTY).

Once PuTTY is downloaded and installed the first step is to set up a secure connection between the Windows system and the remote Linux system with appropriate tunneling configured. When launched PuTTY displays the following screen:

Enter the IP address or host name of the remote host (or the external IP address of the gateway if you are connecting from outside the firewall). The next step is to set up the tunnel. Click on the + next to SSH in the Category tree on the left hand side of the dialog and click on Tunnels. The screen should appear as follows:

Enter 5900 as the Source port and localhost:5900 as the Destination and click on Add. Finally return to the main screen ny clicking on the Session category. Enter a name for the session in the Saved Sessions text field and press save. Click on Open to establish the connection. A terminal window will appear with the login prompt from the remote system. Enter your user login and password credentials.

The SSH connection is now established. Launch the TightVNC viewer and enter localhost::5900 in the VNC Server text field and click on Connect. The viewer will establish the connection, prompt for the password and then display the desktop. You are now accessing the remote desktop of a Linux system on Windows.

[edit] Creating Additional Desktops

In the examples so far we have only covered remote access to the primary desktop. By primary desktop we mean the desktop you see when you sit at your computer and turn on the monitor. While this is fine for a single user system we should not lose sight of the fact that Linux is a multi-user operating system and it will often be necessary for more than one person to have remote desktop access at a time. While it might be fun to watch everyone fight over the mouse point as they share the same desktop it is clear that not much work will get done. The solution to this is to run multiple desktops for the users to connect to.

New desktop environments are created using the vncserver utility.

The desktop we have used so far in this chapter is desktop :0. New desktops must be assigned different numbers. For example to launch desktop 1: run the following command from a terminal window command-line prompt:

vncserver :1

This will start a new desktop in the background ready for a remote user to connect to. To connect to the desktop follow the steps for connecting to desktop :0 outlined above but this time use port 5901 instead of port 5900 (you will similarly use port 5902 for desktop :2 and so on).

When the desktop appears you will notice that it doesn't look much like the standard desktop:

The problem here is that we need to configure the VNC session to launch the correct desktop. To do this shutdown the VNC desktop session as follows:

vncserver -kill :1

Next go to your home folder and edit the .vnc/xstartup file. This will look similar to the following file:

#!/bin/sh

# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

To configure this startup script to launch the standard desktop (known as the GNOME desktop) change the twm& line so that the file reads:

#!/bin/sh

# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &

unset SESSION_MANAGER
gnome-session &

Restart the vncserver:

vncserver :1 -extension XFIXES

Finally, reconnect from the remote system. The full desktop should now appear in the VNC viewer window.

Set up the VNC Server in Fedora

[ thanks copy from http://www.g-loaded.eu/2005/11/10/configure-vnc-server-in-fedora/]
November 10th, 2005 by George Notaras

"Virtual Network Computing (VNC) is a desktop protocol to remotely control another computer. It transmits the keyboard presses and mouse clicks from one computer to another relaying the screen updates back in the other direction, over a network." -WikiPedia-

This article describes in brief how to configure VNC server instances for one or multiple users on a remote machine, how to use VNC to start graphical applications on boot and finally how to enhance security by connecting to the server through encrypted SSH tunnels.

Prerequisites

A user account should exist on the remote machine.
The RPM packages vnc-server and vnc should be installed on the remote machine and your workstation respectively.

Setting up the server

I assume that we have setup a remote user account, named "leopard" and we want to start an X session through VNC for this user.

In Fedora Core or Red Hat based distros in general, all we have to do is define the VNC server instances in /etc/sysconfig/vncservers. These will be started by the vncserver initscript. This has to be done as root. Edit this file so that it contains the following:

VNCSERVERS="3:leopard"
VNCSERVERARGS[3]="-geometry 1024x768 -depth 16"

With these we define that a vnc server instance should be started as user leopard on display 3 and we also set some options for this server such as resolution and color depth. Each VNC server instance listens on port 5900 plus the display number on which the server runs. In our case, leopard's vnc server would listen on port 5903.

For multiple vnc instances /etc/sysconfig/vncservers would look like this:

VNCSERVERS="1:tiger 2:albatros 3:leopard"
VNCSERVERARGS[1]="-geometry 1024x768 -depth 16"
VNCSERVERARGS[2]="-geometry 800x600 -depth 8"
VNCSERVERARGS[3]="-geometry 1024x768 -depth 16"

These would listen on ports 5901, 5902, 5903 respectively.

User Configuration

There is one more thing that needs to be done on the remote machine. User leopard's vnc password needs to be set. So, as user leopard give the command:

# vncpasswd

We are prompted for a password. This is the password that we will use when we connect to leopard's vnc server instance. This password is saved in /home/leopard/.vnc/passwd.

Start the VNC server

After the initial configuration is done we restart the vnc service. As root:

# service vncserver restart

To make VNC server to start on boot:

# chkconfig vncserver on

More User Configuration

After the VNC service is started, some new files are created in /home/leopard/.vnc/ directory. These include leopard's vnc server log file, pid file and an X startup script. As user leopard we edit the script in order to customize some settings. The default /home/leopard/.vnc/xstartup script contains some commands that are executed when the VNC server is started. These include:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

xsetroot in this case sets the background color.
vncconfig is a supplementary program that can be used to control the vnc server. Apart from this, when run without arguments it acts as a helper application and its main purpose is to provide support for clipboard transfers between the client (vncviewer) and the vnc server.
xterm starts an xterm terminal.
twm starts the X server's default window manager. We probably want to change that to a more user friendly window manager, eg fluxbox.

The VNC server, apart from letting us control a remote machine using a graphical interface, it serves as a way to start graphical applications on boot. For example, I want my favourite p2p program, amule, to start on boot. So, I add this to the /home/leopard/.vnc/xstartup script. This is how my xstartup file looks like:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" -e ./menu &
amule &
fluxbox & 

menu is a script of mine that is executed when xterm is started.
Remember to put the "&" symbol after each command, so that it goes to the background and the xstartup script continues on.

Restart the VNC service for the changes to take effect. As root:

# service vncserver restart

Connect to the VNC server

In our example, leopard's vnc server listens for connections on port 5903. So, open this port in the remote machine's firewall.

We connect to the remote machine using a vnc viewer. Having installed the vnc package, connect to to the server with the following command:

# vncviewer 192.168.0.1:5903:3

The general usage is :

vncviewer [Server's IP]:[Port]:[Display]

We are prompted for the password and eventually connect to the server. Closing the vncviewer's window, does not affect the server or the programs we run on it. If we reconnect everything will be there.

Special Note: There is no need, actually it's pointless and could give you some trouble, to logoff from your remote X session. If this happens, generally you need to restart the VNC service on the remote machine to get your remote desktop back. If you want to stop working on your remote desktop, just close the vncviewer's window and you are done.

Security

The VNC protocol is not a secure communication protocol. The use of a vnc password provides security at the level of server access (it's vulnerable to brute-force attacks though), but the whole VNC session is transmitted in the clear, without encryption. The easiest, but most effective, way to secure our connection to the VNC server is to connect through an encrypted SSH tunnel. This way the whole session will be encrypted.

The rest assume that you have the SSH server up and running on your remote machine (server.example.com) and you know what SSH tunnels are.

So, what we are going to do is to create an encrypted tunnel, and connect to our VNC server through it. We also want this tunnel to be automatically closed as soon as we shut down vncviewer. All this is done with the following command:

# ssh -f -L 25903:127.0.0.1:5903 leopard@server.example.com sleep 10; vncviewer 127.0.0.1:25903:3

This is what it does:

• -L 25903:127.0.0.1:5903 forwards our local port 25903 to port 5903 on the remote machine. In other words, it creates the tunnel.
• -f forks the SSH session to the background, while sleep is being executed on the remote machine. This ssh option is needed because we want to execute the following command (vncviewer) in the same local machine's terminal.
• vncviewer connects to the forwarded local port 25903 in order to connect to the VNC server through the encrypted tunnel.

The sleep command is of major importance in the above line as it keeps the encrypted tunnel open for 10 seconds. If no application uses it during this period of time, then it's closed. Contrariwise, if an application uses it during the 10 sec period, then the tunnel remains open until this application is shut down. This way the tunnel is automatically closed at the time we close vncviewer's window, without leaving any SSH processes running on our workstation. This is pure convenience! More information can be found at the Auto-closing SSH Tunnels article.

Using SSH tunnels to conect to your VNC server has two advantages:

1. The whole session is encrypted.
2. Keeping port 5903 open on your remote machine is no longer needed, since all take place through the SSH tunnel. So, noone will know that you run a VNC server on the remote machine.