I'm having difficulties getting MySQL, PHP etc going on fedora 2 so I thought I would reinstall the lot from source as a way to learn and get the latest at the same time. It looks like I should
re-install Apache, Mysql, PHP (lamp).

There is plenty of info on the net, mainly saying the same thing, but I'm a bit confused concerning exactly what I need. Some info I read seems to suggest that the combo PHP/MySQL has to be installed as either an Apache set up OR a CGI set up implying that one eliminates the other. Being new to PHP/MySQL, perhaps there is a peculiarity one must be aware of although Apache and CGI are 2 completely different things.

I want to test 2 new set ups for a Not For Profit organization:
set up 1 is for access to our server through the internet using fast cgi programs written in assembly language that access data files, so far it seems this set up may not need
php/mysql, only Apache, but i'd like to set it up so that, if necessary, I can migrate it to a php/mysql system with a minimum of pain.

set up 2 is for access to another server within a lan with option for a wan later, this set up
will use php/mysql.

I've got a few linux boxes running fedora 2 and networked through an ADSL modem/router and I'd like to know what I need to install on what (client? server?) to test as described above.

Any hint most welcome. If someone could suggest a sort of HOWTO that stand up above the others, that would be a bonus.

Try to keep it simple. This is quite a complex set of stuff to learn from scratch.

I would suggest either a) going back a step and looking at the problem with Fedora Core 2: there are a lot of people here who can help solve specific problems, or b) installing Fedora Core 3 and going from there.

In my experience I've never had to do much more on Red Hat than install the packages, set a root password and user account in MySQL, and perhaps enable CGI.

Compiling from source demands that you understand how all the components hook together, and requires you to manually reset it up when you need to upgrade the pieces. The amount of variables involved in source compiling a complex package are such that posts which say "I compiled from source and have problems" will often get no responses these days.

CGI is a function of Apache that enables it to run programs (usually scripts) and send the results to the browser. Obviously, PHP is one such scripting language that can be enabled. It can run other kinds of executables, so you could run programs compiled from assembler. Out of curiosity - why assembler ?

MySQL is a separate service entirely. The only connection is that PHP includes libraries for connecting to a MySQL database, and that a lot of people run MySQL on Web servers to provide a database for their PHP scripts to work with, because that's the easiest way to do it.

I don't know about HOWTOs, but this is such a popular topic that there are loads of books on running PHP and MySQL on Linux. Most are mediocre, so I would look at the Amazon reviews carefully before choosing which one to buy.

Hope that helps

Thanks to hob.

Your advice is probably the best thing i've read about this particular subject. I think I'll leave the database implementation for professionals when finance permit.

Why assembly? Because it's the only language I know but also because the data exchange in the initial stages has to be extremely fast and another couple of reasons like fast control of data in and out.

I guess that like everybody else, you have to fight to get the time to learn new stuff.

If you are using a network then the effective performance gains of a low-level language will vanish. This is one of the reasons why high-level languages are popular for Web applications - you can use comparitively slow stuff without actually losing anything. Some of the really high performance sites like Amazon use tuned Perl and some custom C libraries, but for most PHP and Java can do the work as fast as the pages can be rendered.

Another reason for using high level languages is that memory allocation errors and other crasher bugs are really, really bad on Web servers. Unlike a desktop application, a bug on a Web server can take out many users and a lot of data. Also, from experience, your publically accessible Web servers will rapidly be found and poked at by automated attack programs, and sooner or later crackers from places that you've never heard of will also probe your systems. Hence the need to update whatever you install - to get newer versions with fixes for bugs and security flaws as soon as they become public knowledge.

PHP and Perl aren't object orientated by default, so you'll probably find these much easier than you think. Depending on the size and nature of the data sets you may find that text files scale surprisingly well, and might be able to avoid the database stuff for some time. Databases can provide a lot of speed through indexing and caching, but the most important reason to look at SQL databases is data integrity - validation of data before it's committed, and recovery when a change fails part way through (power cut etc.) You can obviously backup text files, but you can't revert individual changes ("transactions") without a database. Which may or may not be an issue for you.

This may all sound a little frightening, but if you stick to the road most travelled you'll be fine - use the default packages and apply the updates as they come, keep the firewall enabled, try to use a high level language and the supplied libraries so that you avoid easy and dangerous mistakes.

Good luck.

For a *great* tutorial on building a LAMP server in Redhat/Fedora, I would recommend Bruce Timberlake's tutorial I don't even use Redhat or Fedora but it's an excellent guide, and got me up and running. Good luck with it -- J.W.

Other good tutorials:

eFactory (any distro)
CoolSolutions (Suse)

Thanks to hob & J.W.
I'll have to gain a basic knowledge of LAMP, so L.W's advice is handy, I can experiment with it a bit and learn.

As for hob's advice no 2, it expands advice no 1 very well and is much in line with what i've experienced. So far, i'm using a "flat file" system, I don't think the database we've got is really "relational", it's more a number of sets of data that have nothing in common, not even in structure and this flat file system is easy to administer and use, I've spent considerable time designing it with its use in mind.

Inevitable attacks are something I have to give more consideration too.
Thanks to all for your valuable info.