Advise with install scripts

23 posts / 0 new
Last post
#1 Tue, 09/02/2008 - 23:45
Berilac

Advise with install scripts

Just a quick question regarding the install scripts. When installing them is it better to keep the default "install in sub directory of public_html" or reselect "top level".

Have installed a couple on a test server and had no problems, but with Joomla as its not installed to ITS default directory ( as per Joomla ), I have had some redirect problems, and setting up. And with some extensions/modules not loading correctly.

Not displaying correctly the web site and having to have /joomla at the end of the site address to display anything is a bit of a pain.

Just wondered, any thoughts?

Wed, 09/03/2008 - 02:54
ronald
ronald's picture

i have several joomla installs on my server, all in the top-level and they work fine.
Per haps this is a .htaccess issue and some bugs in specific extensions (openSef for instance).

Normally one would put only 1 script directly in the public_html and any others in a subdirectory, like a forum, helpdesk etc.

Joomla is meant to run in the top-level.

Wed, 09/03/2008 - 11:24 (Reply to #2)
Berilac

Ah let me get this right then. Top level means the root of that virtual server, not the doc root. This can all be very confusing sometimes.

When Virtualmin installs these scripts it gives you the option of install sub_directory under public_html [] At top level [] "app name"

When selecting top level during install an advisory displays warning that other files are installed here already and if uninstalled will be deleted also.

Just checking before I do something terminal. If I select top level it will be installed in the virtual server root and not doc root for that server " /public_html"

Yes it was .htaccess i think, as per question posted in joomla forum, but still couldnt get problem to resolve.

In the script install for joomla the htaccess file is commented out with .txt even when altered to the right file format I was still getting errors displaying on the page and error 500 regularly. Although I have reset php back to cgi and not fcid, that might have had something to do with it.

I guess I am just looking for some direction before installing again, wether to select the first radio button and not leaving it with the default that Virtualmin gives, the second button?

Thanks for the reply ronald

Sun, 06/07/2009 - 07:28 (Reply to #3)
ronald
ronald's picture

a script installation like joomla goes in public_html
this is at top-level for a website as that folder is the public folder. press the first button-> at top level

a second script like a forum goes in a subdirectory i.e /public_html/forum so the folder forum is a subdirectory.

there are two sections in the .htaccess for joomla and depending which SEF url component you use (default or third-party), you select that part in the .htaccess.

This is described in that file if you would open it.
you could also try this in the .htaccess
[code:1]RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !\.(jpg|jpeg|gif|png|js|pl|txt)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php[/code:1]

you dont want the server on CGI but on FCGI instead as its faster.

Sun, 06/07/2009 - 07:28 (Reply to #4)
ronald
ronald's picture

a script installation like joomla goes in public_html
this is at top-level for a website as that folder is the public folder. press the first button-> at top level

a second script like a forum goes in a subdirectory i.e /public_html/forum so the folder forum is a subdirectory.

there are two sections in the .htaccess for joomla and depending which SEF url component you use (default or third-party), you select that part in the .htaccess.

This is described in that file if you would open it.
you could also try this in the .htaccess
[code:1]RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !\.(jpg|jpeg|gif|png|js|pl|txt)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php[/code:1]

you dont want the server on CGI but on FCGI instead as its faster.

Sun, 06/07/2009 - 07:28 (Reply to #5)
ronald
ronald's picture

the two paths / buttons are not the same or should not be the same.
http://izihost.eu/images/install.jpg[/img]

this is what i have in a working joomla 1.5 site

[code:1]
##
# @version $Id: htaccess.txt 9975 2008-01-30 17:02:11Z ircmaxell $
# @package Joomla
# @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
# @license http://www.gnu.org/copyleft/gpl.html GNU/GPL
# Joomla! is Free Software
##

#####################################################
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE
#
# The line just below this section: 'Options +FollowSymLinks' may cause problems
# with some server configurations. It is required for use of mod_rewrite, but may already
# be set by your server administrator in a way that dissallows changing it in
# your .htaccess file. If using it causes your server to error out, comment it out (add # to
# beginning of line), reload your site in your browser and test your sef url's. If they work,
# it has been set by your server administrator and you do not need it set here.
#
#####################################################

## Can be commented out if causes errors, see notes above.
Options +FollowSymLinks

#
# mod_rewrite in use

RewriteEngine On

# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root)

# RewriteBase /

########## Begin - Joomla! core SEF Section
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$ [NC]
RewriteRule (.*) index.php
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
#
########## End - Joomla! core SEF Section

########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits
[/code:1]

Thu, 09/04/2008 - 12:25 (Reply to #6)
ronald
ronald's picture

try the image again :/

<img src='http://izihost.eu/images/install.jpg' style='border:0px'>

Thu, 09/04/2008 - 13:19 (Reply to #7)
Berilac

Thank you ronald for the supplied images, that does make it clearer.

My configuration.php is identical, except the joomla core SEF bit is at the bottom. That wont make any difference, I suspect?

I did put that first little script you posted, in there, but it didnt make any difference. I am presuming that goes in the default web root as the .htaccess

Now for main concern, well the bit i am pondering anyway. The actual installation

If I select at top level, the install will go into the root of the virtual server and not my main root of the server. My worry is to put something into the main root and bugger something up and not be able to recover and end up doing an umpteenth re-install.

What I am aiming for is 3 seperate web sites hosted on individual virtual servers within my own server. Have set those up using Virtualmin. All three are live and working indepentantly.

Now I want to load all the apps to those individual virtual servers for the web sites to be constructed and viewable, with there own independant apps

If I select top level for each script install on each virtual server it is going to be for that server only? and not the main machine.

Bear with me ronald, as you might have guessed I aint no linux/web guru. But am learning, mainly the hard way, crashing and burning alot.

I appreciate the help

Thu, 09/04/2008 - 13:24 (Reply to #8)
Berilac

Cant edit so will do here.

That wasnt the configuration.php shown, sorry, I choose the wrong file name, its the .htaccess and yes the same as yours ronald

Thu, 09/04/2008 - 13:40 (Reply to #9)
Joe
Joe's picture

<div class='quote'>If I select top level for each script install on each virtual server it is going to be for that server only? and not the main machine.</div>

<i>Now</i> I see why you've been sounding so concerned all this time. I couldn't figure out what was triggering your anxiety. ;-)

Yes, Install Scripts install into virtual servers. Virtualmin can't think about problems any other way. (i.e. Virtualmin is not designed to operate on &quot;default&quot; websites or &quot;system-wide&quot; installations of things...though it can be made to do useful instances of that sort of work, if you try...but it won't do anything by accident.)

--

Check out the forum guidelines!

Thu, 09/04/2008 - 13:52 (Reply to #10)
ronald
ronald's picture

<div class='quote'>If I select at top level, the install will go into the root of the virtual server and not my main root of the server. </div>
Im not sure what your confusion is here.

you create a domain.
it creates: /home/domain1.com
to be visible to the outsideworld your joomla goes in /home/domain1.com/public_html (top level)

the same for
/home/domain2.com
/home/domain3.com

through the install script module Joomla will never be installed outside the public folder for that domain, only &quot;deeper&quot; like /home/domain1.com/public_html/joomla

you must login as the virtual server owner, i.e. domain1.com and then install joomla

the .htaccess I posted is the original joomla file.
read the orange comments, if you have trouble somehow you can comment some rules out

You can also disable sef in joomla backend and see if it then runs fine. if not, disable non-core extensions and enable 1 by 1 to see which one causes trouble.

Thu, 09/04/2008 - 13:58 (Reply to #11)
Berilac

thanks ronald it was just the term root which was putting me off. You have convinced me. Will reinstall in the top level tomorrow. It was the &quot;if you delete at a later time&quot; thing that was putting me off.

I MUST BE MORE CONFIDENT IN WHAT I DO EVEN IF I DONT KNOW WHAT I AM DOING

Thu, 09/04/2008 - 23:15 (Reply to #12)
Berilac

Right I am going to do this.

Only thing is scipt installation is not available for each virtual server, I can only install into each one via the main Virtualmin login and selecting by each one from the drop down menu at the top left.

There is no option &quot;install scripts&quot; on the admin page for the domain of the individual virtual server.

So will install via the master to that domain.

Thu, 09/04/2008 - 23:38 (Reply to #13)
Joe
Joe's picture

<div class='quote'>Only thing is scipt installation is not available for each virtual server, I can only install into each one via the main Virtualmin login and selecting by each one from the drop down menu at the top left.</div>

This behavior is configurable (as all things in Virtualmin are). If you want to allow virtual server owners to install scripts (I think most folks do, but the defaults are based on principle of least necessary privilege, on the assumption that it's better to err on the side of too little than too much). Just look in the Edit Owner Limits page in the Administrative Options menu.

In the &quot;Allowed capabilities and features&quot; section check the box labeled &quot;Can install scripts&quot;. This can be set automatically for new virtual servers in the Server Templates (once again, as nearly everything in Virtualmin can be).

--

Check out the forum guidelines!

Thu, 09/04/2008 - 23:47 (Reply to #14)
Joe
Joe's picture

Oh, and I guess I didn't make it clear:

It doesn't matter if you're logged in as the &quot;root&quot; level user, or the virtual server owner. Everything you do in the virtual server menu (that's the section above the line followed by System Settings, and ending with Logs and Reports) is done the exact same way as it would be if the virtual servcer owner had that menu item and used it themself--again we're back to the basic model of Virtualmin. It isn't possible to manage non-virtual servers in Virtualmin. e.g., you <i>can't</i> install a script in some non-virtual server location using Virtualmin. It has no idea about things that aren't virtual servers.*

When you select a virtual server in the dropdown list and install a script, the script is installed just as it would be <i>as the owner of the virtual server</i>, and assuming suexec is enabled (as we always recommend), it'll actually be owned by the owner of the virtual server. Virtualmin is all about virtual servers--the notion that it could do otherwise is tripping up your understanding of what Virtualmin is going to do when you click on stuff. ;-)

* (a note on the above comment about what you can't do in Virtualmin)- While you can't install anything into a non-virtual server type Apache host, you <i>can</i>, and many people do, setup &quot;system-wide&quot; applications using Virtualmin and a ProxyPass rule or two, or just a single domain for those &quot;system-wide&quot; applications. SquirrelMail is one such app that commonly gets setup that way for webmail, because some folks find Usermin unfamiliar and prefer something better known. And that's OK--works fine, is easy to do, and doesn't go against anything I've said above. It's still installed a virtual server.

--

Check out the forum guidelines!

Thu, 09/04/2008 - 23:54 (Reply to #15)
Berilac

ah ok then will continue then.
Tried having a look around to see if I could enable some setting somewhere to have script install available under each virtual admin login, but couldn't.

Here goes, deep breath and...............

Fri, 09/05/2008 - 00:15 (Reply to #16)
Berilac

Well I think we can put that little baby to bed now, I can see the difference top level install has made. And yes my temp index.html comes up now in the preview and not the default joomla one so something has worked haha.

All I need to do now is get something meaningfull up and going on there!!

Just wondering why, a forum persay goes into a sub folder? So it doesnt get root access maybe?

Thank you guys for steering me thru my little dilema

Fri, 09/05/2008 - 12:10 (Reply to #17)
ronald
ronald's picture

a forum doesn't go per se into a subdirectory.
If you like you can put it at top level.

commonly used is a website (homemade or cms-like) at the top level as that is the presentation of whatever meaningful stuff you do and a link in the menu to a forum.

In that case you must put a forum in a subdirectory as no two scripts can co-exist in a folder. Often 2 scripts both have an index.php and a folder images, you see the bottleneck there ..

If all you have is a forum, then put it in top level so it can be called in a browser by the domain name ..

However you do it, root access has nothing to do with it.

<div class='quote'>I MUST BE MORE CONFIDENT IN WHAT I DO EVEN IF I DONT KNOW WHAT I AM DOING</div>
if you don't know what you're doing I suggest to find out what you need, before actually doing it. One never knows what damage could be done otherwise.

Would be a good thing to set up an old computer (or dual boot on your PC) as a development server so you can test before doing it at the production server. Most sysadmins do this.

Fri, 09/05/2008 - 12:17 (Reply to #18)
ronald
ronald's picture

<div class='quote'>It doesn't matter if you're logged in as the &quot;root&quot; level user, or the virtual server owner. </div>

to install scripts it doesn't matter however in my opinion it is generally always best practice to not log in as root if it isn't absolutely necessary or if you absolutely make no fatal mistakes.

Wed, 09/03/2008 - 14:33
Berilac

Now I am even more confused than before. If I select the &quot;first button&quot; the installation says that it will install in sub folder /home/xxxxxxxxxxxxx/public_html/joomla, and to warn that other files exist and will be deleted if joomla is deleted. If I just leave it at what Virtualmin defaults to &quot;the second button&quot; and joomla entered in the dialog box, it installs to the same place anyway. Whats the difference? Surely,
/home/xxxxxxxxxxxx/public_html/joomla and
/home/xxxxxxxxxxxx/public_html/joomla are the same thing, I cant see the difference?

As for .htaccess, there was only default showing, no 3rd party section. I tried the codes given in the forum(joomla) but no good, unless I typed someting wrong?

Sorry for being a bit of a dumb arse ronald, and thanks for that code will give it a try.

Um its late, a good nights sleep is required and perhaps with a clear head, I might be able to sail thru this.

Thu, 09/04/2008 - 00:02 (Reply to #20)
Joe
Joe's picture

You're not being dumb. If Joomla doesn't work after installation into /joomla <i>or</i> / then it's a bug that needs to be fixed. File a ticket in the tracker with the details of what doesn't work.

Of course, if you're installing additional Joomla modules that tinker with paths, all bets are off, and you'll have to get the configuration of those additional modules right yourself.

Our Joomla installation here at Virtualmin.com is installed into the document root (/home/virtualmin/public_html). All of the other applications we have installed (just Flyspray, I think, as Dokuwiki was part of the Joomla component/bridge) are in sub-directories. This <i>is</i> risky, if you plan to ever uninstall the application--Virtualmin doesn't know everything about the application, and everything that you add to the application later (such as plugins or whatever), and so when you uninstall an application, it deletes everything in the directory that has the application. If that's the document root, it'll delete everything, including any non-app data. This is mildly bug-like, but the only solution is to build a full-featured package manager, which is a dramatically more complex task than the value it would provide (RPM and dpkg, for example, took years to develop). We will continue to refine the uninstall aspect of things...and make the Install Scripts data more comprehensive, gradually. But don't expect major changes to this particular behavior anytime soon, as it so rarely effects folks...except those who are tinkering with their site, which means they don't mind starting over each time they try a new app.

Anyway, it's also possible to install into /joomla and use a proxy rule to forward over to the app, but that's probably more trouble than it's worth.

I would suggest you make it the root app, and only install things that you plan to be part of the same site (e.g. bridged into Joomla) in subdirectories of that. Any apps that you also want, but won't be bridging in, create a new sub-server with a different domain (e.g. if I didn't care about all of our apps sharing a login and session, I could do something like forum.virtualmin.com and bugs.virtualmin.com ) and install them there. This solves all of the problems with mingling apps. (It does introduce some new problems with cacheability of resources, if your site is really heavy and design elements and JavaScript are the same for all sites.)

--

Check out the forum guidelines!

Thu, 09/04/2008 - 00:35 (Reply to #21)
Berilac

Thanks Joe, yeah I want to keep it as simple as possible, I aint no pc expert. This is just to get a couple of community web sites going. They will be extinct before I finish ha ha.

It was the install paths that were confusing me.

On the script installation options page it jives you the option:
Install sub-directory under public_html [] At top level [] &quot;text box&quot; with joomla already in there.

I take it the first button is to install into a sub directory and the second is to top level. Even when I leave it at the second button it installs in ../public_html/joomla
Thats the bit that confuses me, they are one and the same arent they. I mean they both go into ../public_html
I haven't tried the first button option, to see were it goes, because of the deletion warning.

Thu, 09/04/2008 - 01:19 (Reply to #22)
Berilac

Righto, have re-installed and seems to be ok, well pages are being displayed anyway. Even tho different. I glad I not in the IT business, I wouldn't last very long and definately wouldn't become the next Bill Gates ha ha.

http://postrangersgolfsociety.org.uk
http://postrangersgolfsociety.org.uk/joomla