I have a Linux (CentOS) host that hosts 5 websites of mine. There are two different PHP frameworks (Yii & Zend), each of my sites is based on one of them. Where would be an appropriate place to keep them, with what permissions? I though of two variants but I have doubts that any of them is the right thing to do.
In my projects, which reside in for example /home/example.com/public_html/index.php I would do require_once($pathToFrameworkInitFile)
Variant 1:
Under /usr/local/, user root with permissions 755:
/usr/local/frameworks/yii/yii-1.1.9/
/usr/local/frameworks/yii/yii-1.1.10/
/usr/local/frameworks/zend/zend-1.11.12/
Variant 2:
Under user frameworks with permissions 755:
/home/frameworks/yii/yii-1.1.9/
/home/frameworks/yii/yii-1.1.10/
/home/frameworks/zend/zend-1.11.12/
Variant 3:
I hope that you might suggest something better.
As you suppose - I have full root access to the host and I'm managing both websites and host myself, so I'm looking for the best (or at least good enough) practice.
After reading more about the Unix FS Hierarchy Standard, I decided to put the frameworks in:
/opt/php-frameworks/yii-(version)
/opt/php-frameworks/zend-(version)
With permissions 755, under the root account. Most best practices say that the framework should be out of the docroot and /opt seems ideal for such libraries as php frameworks.
This is very subjective. You can put it where you want. I liked to put the webapplication in /opt/www/project or /var/www/project.
And I don't like to share the framework parts of the application. Think about moving a Project to a new Server, or updating the frameworks.
The owner has to be the user who changes the files. If you are root, then let root own the framework files.
Related
I made a program trying to see how many color pages are on an uploaded PDF file, using Ghostscript. Now, it worked perfectly on my local environment, but I can't put the site online, as the web hosting service I use tells me that any application that needs root access cannot be installed on the server. Is it the case with Ghostscript, and if so, is there any other way I can use it ?
I'm new to all this, and I know now I should have asked the web hosting service first thing, but I'd really like to not have to put my work in the bin over this !
No Ghostscript doesn't require root privileges and I've no idea why they would claim it does. Also, I would strongly urge you to review the AGPL license.
Let say i have a cross-platform runnable application
This application create then read/write some data and preference in external files
Bundle hierarchy is as follow:
ApplicationFolder/application.jar
ApplicationFolder/database.odb
ApplicationFolder/config.xml
Whether it's on a Mac, Windows or Linux, the application knows that everything is next to her (ie: /database.odb or /config.xml)
Now comes the Self Contained Application feature provided by JavaFx 2
The application is embedded in .exe on Windows, .app on Mac and don't know yet about Linux...
As a Mac user i've tested it on Mac and saw that database.odb and config.xml are now created at the user root path
I thus agree that i should think of a cross-platform mechanism to save/read my application preferences regarding the operating system
But i'm not quite sure of what to do and how to do it (can't find any googling help either..)
On windows, the .exe is installed in a folder, so i guess i can keep the same behavior
On Mac, the .app is a folder and i should keep everything inside (how to get the .app path ?!)
Isn't there a built-in mechanism in Java/JavaFx ?
Thanks a lot for any comment, advice, documentation or else that you could give me
Badisi
There are many ways to do this. I have listed some of them here in no particular order. The recommended approach depends on the type of data being stored.
Java provides a couple of mechanisms (e.g. the properties API and the preferences API) for maintaining application preferences.
If your application is sophisticated enough to benefit from an database, then you might want to use Java EE or Spring, both of which have their own configuration mechanisms.
For read-only configuration, you can bundle the relevant files inside your application jar.
To store customized application configuration files or client application wide databases in relative to the application jar, write the required files at runtime. See How do I get the directory that the currently executing jar file is in?.
For user specific configuration, use System.getProperty("user.home") to retrieve the user's home directory, then create a subdirectory for your preference storage (for example "{$user.dir}/.myapp") with hidden file attributes so that it doesn't show up on a standard file directory list.
If your app relies on internet connectivity, then you can store some of this information server side rather than the client and make use of it from the client using internet protocols. An advantage of this approach is that user configuration and data is automatically ported across client machines.
I am setting up a new SVN server on Ubuntu Linux. Where is a good place (best practice) to put the repositories? Should I create a new user? The server will be accessed via http:// so no need to create user accounts etc (as was the case for svn://).
Many thanks in advance
I like putting things under /srv, as it seems to match the definition in the FHS.
The new location for service data according to the FHS is /srv, so under there would probably be best.
I've always used /var/svn or /var/lib/svn. While it doesn't quite line up with FHS, it matches closer to what the other apps actually do (On RHEL5, Apache uses /var/www; PostgreSQL uses /var/lib/pgsql). As suggested, /srv/svn looks like another good spot. And you get to say "Look, I'm following the standard!"
Using either /usr/svn or /usr/local/svn would probably be considered bad form, and all your Linux friends will laugh at you behind your back :-)
I host my SVN via the apache module, so I usually put it under my apache user, at the same level as my htdocs, and setup a specific authentication just for SVN users. Not under htdocs, but same level.
If you have a lot of projects, dedicate another volume to SVN since it will grow.
I guess I'm kind of old school but I like to put things (apache,tomcat,...etc) in /usr/local. So I will usually create repositories in /usr/local/svn and have the Apache module reference that path in the httpd.conf
/home/username/Dropbox
this way you backup the svn and can access it on a windows machine as well.
What files should/should not be stored in the cgi-bin folder/directory on a web server?
Obviously, executable scripts/files that make up a web application, called from a web browser can be stored there.
But is there a common industry opinion about what else can be stored there?
Is there a very strong reason why nothing else apart than the scripts/executables is allowed there?
My preference is to store all files belonging to an application in the cgi-bin directory/folder, as a subfolder off it - for each application.
For example directory cgi-bin/myapplication would contain:
the cgi scripts/executables
datafiles
configuration files
This simplifies installation and also simplifies the steps to run different versions of a application in parallel, e.g. for trialling a new version.
Concerns about security access to non-script files can be addressed by using the correct user permissions and also Apache .htaccess to control access to the directory and files.
It would seem that popular free applications are in favour of this everything-under-one-directory approach: The versions of bugzilla, the free defect and feature tracking tool, e.g. 3.4.4 are offered in this structure, while earlier versions, e.g. 2.x installed bugzilla components to at least three folders.
Drupal, the powerful and popular free content management system also takes this approach of everything-under-one-directory, albeit doesn't use the cgi-bin folder but the approach is the same.
What are your thoughts?
There is nothing special about the cgi-bin folder. It is like any publicly-accessible web folder that has the "allow-script" flag set (or the equivalent for your web server) - something that has become almost meaningless in the world of PHP/JSP and the likes.
You should only store files that you wish to be public in any folder under your webroot. You probably don't want your data and configuration to be downloadable by any user on the internet, so don't keep them in /cgi-bin
Certain servers may try and execute any file in /cgi-bin if requested. This could cause problems, especially if text or data files are executed as shell script.
Applications like Drupal are intended to be easy for anyone to install, regardless of what permissions they may have on their web-host. This is the main reason it keeps everything together. If you have the ability to put files where you want, it is always a good practise to keep non-public files outside of the webroot. If you must keep them under the webroot, then ensure that you use your server's configuration to deny public access to the non-public files.
There are lots of similar questions to this, but they all seem to involve either configuring permissions or installing a plugin.
I'm looking for a solution that is "dumb" - i.e. to allow the code to be deployed from source control and automatically have access to certain paths blocked, without anyone needing to configure the server.
I only need directory & file blocking, none of the other abilities that .htaccess has.
Just to be clear, we are using ColdFusion, not .NET, and whilst CF has assorted ways to handle its own scripts, it doesn't do anything with non-CFML scripts. (It is possible to do, for example config.xml.cfm, but that is a messy solution that requires updating code, etc.)
(Of course, ideally these directories/files shouldn't even be in the webroot, and if I could switch to Apache or IIS7 I could simply use .htaccess, but those aren't options at the moment.)
My current solution is going to be a readme.deploy.txt that contains instructions on how to manually set the permissions on the relevant files & directories in IIS Manager, but obviously I'd much prefer to avoid human intervention for it - any suggestions?
You could create a script that would do this when you cycle through your deployment, like say a scheduled task where you use a PowerShell script or batch script that sets up the enviroment.
With IIS6 this is going to require mucking with the Metabase, which could solve your problem, but it will require scripts to have access to the system metabase and execute system commands or you going to have to learn how to use the ii6 metabase command files
see this This Article
If they have root access maybe it would be wise to just create a installation utility that can tweak the settings for them.
Good luck,
mike
Well, for ASP.net specifically you have the .config files which allow you to control some aspect of those web folders.
However, I'm not aware of anything like .htaccess for IIS.
.NET has Routing which allows you to 'rewrite' paths. The MVC framework has it built in... I'm not sure on how to configure/use it for 'normal' ASP.NET applications.
Update: didn't know you weren't on .NET.
Maybe you're just looking for File/Folder permission settings? Don't know anything about setting those by using a config file...