Steps 3 and 4 only apply if you are upgrading from MySQL 5.0.x

Step 1) Set up the atomic channel:
wget -q -O - http://www.atomicorp.com/installers/atomic | sh

Step 2) Upgrade to Mysql 5.1
yum upgrade mysql

Step 3) MySQL 5.1 removed the BERKLEY storage engine. Since it was not commonly used, to save resources it was recommended this be turned off. You must comment the following out or remove it from /etc/my.cnf or MySQL 5.1 will not start!
skip-bdb

Step 4) Update your MySQL tables
mysql_upgrade -u admin -p

Step 5) Restart mysql
/etc/init.d/mysqld restart

To upgrade to PHP 5.3.x on plesk 10:

Plesk doesn’t ship client’s PHP, it only downloads it from original OS vendor repo and it is quite likely it may be outdated there (especially for older OS). If your OS comes with PHP 5.3, then Plesk would run PHP 5.3 for clients. When you upgrade mysql  php has to be updated automatically, but in case..

Step 1) Set up the atomic channel:
wget -q -O - http://www.atomicorp.com/installers/atomic.sh | sh

Step 2) Upgrade to PHP 5.3.x:
yum upgrade

Step 3) Replace the PHP 4 php.ini with PHP 5.3.x’s (if applicable):
mv /etc/php.ini.rpmnew /etc/php.ini

Step 4) Replace the php.conf with the PHP 5.3.x php.conf (if applicable):
mv /etc/httpd/conf.d/php.conf.rpmnew /etc/httpd/conf.d/php.conf

Step 5) Restart the webserver
service httpd restart
(or)
/etc/init.d/httpd restart

Checklist

1. Source code installations of extensions, like Ioncube loader, or other extensions that have to be updated.
2. php.ini settings, like memory_limit

In your user account, not as root (bad form and all) make the following directories:


mkdir -p ~/rpm
mkdir -p ~/rpm/BUILD
mkdir -p ~/rpm/RPMS
mkdir -p ~/rpm/SOURCES
mkdir -p ~/rpm/SPECS
mkdir -p ~/rpm/SRPMS
mkdir -p ~/rpm/tmp


And create an ~/.rpmmacros file with the following in it:


%packager Your Name
%_topdir /home/YOUR HOME DIR/rpm
%_tmppath /home/YOUR HOME DIR/rpm/tmp


And now comes the fun part. Go to the ~/rpm/SOURCES directory and create a working package directory under that with the package name and a dash and the major revision number. For example, ~/rpm/SOURCES/linc-1. Now in that directory you will copy all the scripts/files that you wish to have in your package. For example, I might have a script in that directory called myscript.sh that I want to be installed as part of the linc package.

Once that is done, make a tarball of that directory in the ~/rpm/SOURCES directory named programname-revision.tar.gz. Using my previous example it would be:

tar czvf linc-1.tar.gz linc-1/


Now for the glue that makes this all stick together. Go to your ~/rpm/SPECS directory and create a spec file for your package. We’ll call mine linc.spec and it’ll look like this:


Summary: My first rpm script package
Name: linc
Version: 1
Release: 1
Source0: linc-1.tar.gz
License: GPL
Group: MyJunk
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-buildroot
%description
Make some relevant package description here
%prep
%setup -q
%build
%install
install -m 0755 -d $RPM_BUILD_ROOT/opt/linc
install -m 0755 myscript.sh $RPM_BUILD_ROOT/opt/linc/myscript.sh
%clean
rm -rf $RPM_BUILD_ROOT
%post
echo " "
echo "This will display after rpm installs the package!"
%files
%dir /opt/linc
/opt/linc/myscript.sh


A lot of that file is pretty self explanatory except then install lines and the lines after %file. The install lines tell rpm what to install where and with what permissions. You also have to do any directory creation there as well (the one with the -d in the line). The things after %file are similar in that this tells rpm’s database which files are attached to this package. The %dir signifies a new directory, otherwise the files are listed with their complete paths.

Now that you have all that together. The last thing you need do is create the package. Just go to ~/rpm and do an “rpmbuild -ba SPECS/linc.spec”. You will end up with an ~/rpm/RPMS/noarch/linc-1-1.noarch.rpm if all goes well.

Esistono CMS specializzati, cioè appositamente progettati per un tipo preciso di contenuti (un’enciclopedia on-line, un blog, un forum, ecc.) e CMS generici, che tendono ad essere più flessibili per consentire la pubblicazione di diversi tipi di contenuti.

Tecnicamente un CMS è un’applicazione lato server, divisa in due parti: la sezione di amministrazione (back end), che serve ad organizzare e supervisionare la produzione dei contenuti, e la sezione applicativa (front end), che l’utente web usa per fruire dei contenuti e delle applicazioni del sito.

I CMS possono essere programmati in vari linguaggi tra cui più comunemente in PHP e ASP; il tipo di linguaggio adoperato è indifferente a livello di funzionalità. I CMS in PHP sono multipiattaforma, mentre i CMS in ASP possono essere utilizzati solo su piattaforme Windows.

Ecco una lista (in ordine alfabetico) dei CMS open source più utilizzati:

• Alfresco [1]
• Docebo CMS [9]
• Drupal
• eZ publish [11]
• Fedora Commons[12]
• Joomla!
• LG-Nuke
• Magnolia [19]
• Mambo
• Nuke-Evolution
• OpenCms
• PHPNuke [30]
• Plone
• PostNuke [31]
• Typo3
• WordPress
• XOOPS

Esiste un grande ventaglio di offerte, in funzione dell’uso che si vuole fare del sito web.

Un servizio tipico, per un sito statico, può tra l’altro comprendere:

• Registrazione o trasferimento di un nome di dominio
• Da tre a 10 indirizzi di posta elettronica, con eventuali alias
• Filtri antispam ed antivirus
• Un determinato quantitativo di spazio web
• Gli strumenti adatti alla gestione delle pagine, quali file manager, prototipi, ftp, contatori di accesso, ecc.
• Una quantità di banda mensile per il traffico generato dal sito adeguata

per un sito dinamico può comprendere, oltre a quanto già citato:

• Il supporto ad uno o più linguaggi di scripting, come ad esempio PHP, Python, o ASP
• il supporto ad un database on line, come ad esempio MySql o Postgres
• servizi di statistiche e analisi del traffico, come ad esempio il software libero webalizer