Does +FollowSymLinks work with Windows shortcuts? It seems it is completely ignored by Apache under Windows 10.
The importance of this is that, some web frameworks, like Laravel, use this directive to access storage folder (or any other folder outside the public directory) throughout symbolic links. Then, these features are simply ignored in Apache under Windows.
Could anyone, more experienced than I, conform or explain me that? Could you also tell me if there is any workaround?
Thanks for any help!
Shortcuts aren't symbolic links, that's not the same. In order to put a filesystem reference to a file or directory on Windows, you need to use mklink command in either CMD or PS console.
As for Laravel, it ships with no outside dependencies, meaning everything Laravel needs to work aside from PHP itself should be located in the served directory, minding the path in configs. As far as I know, Laravel doesn't use any kind of symbolic links as it is platform-independent, meaning that as long as you have PHP properly configured and compiled with needed extensions, it will work anywhere. It even ships with a default .htaccess used for routing inside /public directory, at least in Laravel 8.
The way Laravel files reference each other is rather simple, check relative paths. Mind they are also implemented as a part of filesystem in any Windows or *nix systems and behave similarly if not identically.
I propose to store the project as is in the config-defined directory and work on your code from there.
Related
I have the following WebSphere Liberty file layout (with a few choice directories and files show) which uses a custom usr dir of wlp-usr.
wlp/etc/server.env
wlp-usr/servers/server1/apps/
wlp-usr/servers/server1/extension/
wlp-usr/servers/server1/resource/
wlp-usr/servers/server1/bootstrap.properties
wlp-usr/servers/server1/jvm.options
wlp-usr/servers/server1/server.xml
wlp-usr/servers/server2/apps/
wlp-usr/servers/server2/extension/
wlp-usr/servers/server2/resource/
wlp-usr/servers/server2/bootstrap.properties
wlp-usr/servers/server2/jvm.options
wlp-usr/servers/server2/server.xml
The file wlp8554/etc/server.env contains
WLP_USER_DIR=/home/me/wlp-usr
I want to get the servers (there will be more than 2) using their own extension folders, rather than the default wlp-usr/extension/lib.
The documentation on Liberty directory locations and properties suggests that usr.extension.dir is what I want. http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.wlp.nd.doc/ae/rwlp_dirs.html?cp=SSAW57_8.5.5%2F1-3-11-0-2-3
I have tried setting this in bootstrap.properties and jvm.options, but without success. I am wondering if this is a read only property or if it is something that I can actually set. Has anyone used separate extension directories before? Is this even possible? If so then some guidance on how would be most appreciated.
Cheers, Steve
The usr/extension directory is per-user-directory, so it is effectively read-only from a server perspective (all the variables on that page are derived and cannot be changed except wlp.user.dir, which can be set by WLP_USER_DIR, and server.output.dir, which is derived from WLP_OUTPUT_DIR). That is, it is not possible to have per-server extensions. If you really need that capability for some reason, then I would recommend opening an RFE.
That said, usr/extension is really intended for convenience during feature development (or perhaps for minor deployment scenarios). Product extensions are really intended to be applied to an entire installation, so they should probably be used for any sophisticated environments. Since individual servers are unaffected by extension features unless they enable them, there should not be much reason to have per-server extensions anyway.
I'm on OS-X (Mavericks, if that matters), and I'm making a bash script that will use resources from a folder called "templates". I'm trying to figure out where I should put it (the templates folder). I'd like to make it so the user doesn't need to modify their path when they install it, so I'd rather not do it the way the terminal mysql command does it (it lives in a folder in /usr/local/mysql/bin). I really want to be able to put them into usr/bin, but I don't know if it's "polite" to put folders in there (I don't see any in there).
Right now I'm leaning towards putting the scripts in usr/bin and having the templates in usr/lib. Is that how this type of thing is normally done, or is there another way? I'd like to follow a convention, assuming there is one. I'd also like it to apply to as many Unix platforms as possible (I'd like to put in a directory where bash scripts live that's consistent across as many Unix platforms as possible). Thanks.
If you follow the Filesystem Hierarchy Standard (FHS), your executable goes in /usr/local/bin, while read-only template files go in /usr/local/share/YOURAPP/. To quote the FHS:
/usr/local/share
The requirements for the contents of this directory are the same as /usr/share. […]
and:
The /usr/share hierarchy is for all read-only architecture independent data files.
(Emphasis added)
If the system admin is meant to customize the template files to take effect system-wide, then they would simply go in /etc/YOURAPP/templates (or something like that).
If the template files are customized on a per-user basis, then the modified copies of the templates (copied from /usr/local/share/YOURAPP/templates) need to be saved in the user's directory, under $HOME/.config/YOURAPP/templates or something like that (thanks to technosaurus for the correction).
You mentioned that you want to install the templates in a directory alongside your executable. That is not the standard approach on UNIX, at least going by the FHS. If you really want to go this route, there is a sort of convention of installing your app to /opt/YOURAPP/, using whatever organization you want inside that folder.
In all cases, it is not good practice to install executables directly to /usr/bin, as that directory is considered to be under the exclusive control of the OS/distribution. If you want to install there, the accepted way to do that is to create a package for the package manager of every supported OS/distribution.
If i've built a web app using code igniter, what's the proper way to deploy it? Should my install only include my files, or do I also package all the codeigniter code with it?
I'm just entering into the world of open source so I'm not so sure what protocol is.
Thanks.
This is a good question and I've seen it done both ways. There's definitely reasons Not to include the CI files. Like any potential in the future license changes. And it seems like with the projects that are shared by more experienced developers that is how they do it.
Because if you are sharing your project for other CI developers, then the reality is they will not use the copy of CI you include - they will fold your files into their version of CI. So including JUST the files needed for your app - actually makes much it easier. Its certainly what I would prefer. Just keep the standard application folder structure: config controllers models etc. but only include the folders that you have files for. And make it clear what version of CI you have tested it on. If you can say it will work on the release version (not the beta) then people on PHP 5.2 will know they can use it.
Of course you need to include all the CodeIgniter files, or else how would it run?
Most people tend to rename the application and system files and place them outside of the web root for security reasons. "After moving them, open your main index.php file and set the $system_folder and $application_folder variables, preferably with a full path, e.g. '/www/MyUser/system'".
Google turns up nothing but very basic set up of web servers on the Mac. I've got that.
I build web projects locally on a Mac using PHP/MySQL. I store the sites in /Library/WebServer/Documents then access them via browsers with http://localhost.
This works fine.
What I would like to do is to be able to place symlinks or aliases of projects into the /WebServer/Documents folder and access sites on other (local) drives. I don't want to have to store everything in the Library folder. However, it seems that symlinks don't work. The only way a project functions is if all it's files are located in the /Library folder - no symlinks.
I realize I can change the root path for the web server in the http.conf file but I don't want to actually change the server path, I merely want to use symlinks if possible. I also realize I could use something like MAMP, but things run fine with my traditional set up (and I prefer to avoid MAMP since it's not always real-world). Main motivation here is that I don't want to store files on the boot volume, where there Library folder is located.
Can I use symlinks for directories with Mac OS10.6.8/Apache? if so how, please?
Thanks!
Solved via this article at Apple:
http://support.apple.com/kb/TA21182?viewlocale=en_US
One must specifically create a symbolic link. Which, it appears, is not the same as an Alias on the Mac OS.
But this isn't feature of MAMP application, this is about web server. Make it through MAMP and go see what is new in apache config files (httpd.conf, vhost.conf).
you have to use symlinks instead of an alias... sad there is no ui for that!
you have to go into the Terminal and type:
ln -s /ORIGINALPATH /LINKEDPATH
the first PATH is the base path of the original file and the second is for the base path for the symlink of the file/folder etc
I want to put my dependent files in the app directory.
I seem to remember that you can force VB6 to use the files in the local directory only.
Any hints?
You may also want to try setting up Reg-Free COM for your project. There's a freeware called Unattended Make My Manifest that will do most of the work for you.
Placing component libraries in the EXE folder (with or without .local files) can be deleterious to the hygiene of target machines too.
VB6 programs will register the components here via the self-reg entrypoint behind your back if they are not previously registered. Then if the application is moved or removed you leave the user with a broken reigistration - possibly fatal to subsequently installed applications using some of the same components. This is probably fine though for application specific components, i.e. your own DLL or OCX that will never be needed by another application.
The .local trick was really not meant for use with VB6 programs and if it is used your installer needs to be aware and properly install and register the components if they are not already on the machine. It was meant as a manual hack to get around DLL version compatibility problems on individual machines, not a deployment strategy.
Move up to SxS application and assembly manifests (Reg-Free COM and more) for a better solution. DLL/COM Redirection (.local) was a good try but it has many warts.
Clay Nichol's answer about the search order is not quite correct. That search order only applies to non-COM components. I.e. only some DLLs, and not OCXs. If you register your COM objects, they will be used from the directory where they are registered regardless of what's in the local directory, unless you use reg-free COM or a .local file.
EDIT:
MakeMyManifest is well spoken of as an automatic tool for creating manifests for VB6 projects, haven't tried it myself.
DirectCOM also has fans, again I haven't tried it.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
There is a semi-automatic technique to generate reg-free COM manifests. You can create the manifests with Visual Studio 2008 (you can use a free version like Visual Basic Express Edition). Then make a couple of edits by hand to make the manifests suitable for use from VB6. See this section of this MSDN article for step-by-step instructions - ignore the rest of the article which is about ClickOnce.
It can be sort of confusing because every version of windows, the rules change. Older versions of Windows search the path before the current directory.
A simple solution without manifests:
If your executable file is A.EXE, add a (0-byte, empty) file in the same directory named A.EXE.local -- for older versions of Windows this puts the app directory ahead of the path in the search order.
Found it myself:
Windows does look in the App Directory first:
If SafeDllSearchMode is enabled, the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If SafeDllSearchMode is disabled, the search order is as follows:
1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
according to : http://msdn.microsoft.com/en-us/library/ms682586.aspx
But you can redirect where it looks for .dll's using a Manifest:
http://msdn.microsoft.com/en-us/library/aa375365(VS.85).aspx