I'm wanting to compile MySQL into a user-specific directory on my Mac. I know how to compile it and everything, it's just the directory selection I'm looking for. The question starts at:
Is /usr/local user specific? If I installed it into there while on an active user Bob, will Joe be able to see and access it, or only Bob?
I suspect that's not the case. If it is though, then great! If it's not, then where would be the best place to compile and install stuff such that I can have that control over which users can see and access it?
Keep in mind these are for more complicated stuff like compiling MySQL so I don't want them in some generic applications folder (which is why /usr/local would be great if it had this user specific-ness)
/usr/local is system specific... so yes Bob would be able to use it. U usually keep a dir stucture uner my user home so:
/Users/username/
lib/
bin/
etc/
You could install it there. That said you could just modify the user and group settings for the execute permission to a group only you and the system belong to. Im actually thinking that would be the better way to go here since having it in your home dir might make for more hurdles since youll probably want to run the mysql server as a daemon.
Related
I have configured MAC OS X environment (SDKs, licenses, etc) under current user for build server and would like to reuse all the settings by a build agent. Jenkins was chosen as a good option but for some reason during installation it created a new user jenkins and launch the app under it, causing the environment setup to be not accessible (no SDKs, no licenses are found anymore).
Is it possible to install jenkins under current user?
Probably it could be installed under jenkins but then launched under current user?
Any other good options for me to consider are appreciated.
Try this: http://www.sailmaker.co.uk/blog/2013/04/02/advanced-jenkins-for-ios-and-mac/#Installing-Jenkins-itself
I’m also going to recommend installing Jenkins via Homebrew, to avoid
some nonsense in Jenkins’ own installer whereby it puts itself in
/Users/Shared/. You really don’t want that.
If you're free to reinstall however you'd like, I'd recommend re-installing as the user you want to use, using whatever type of install you prefer, and then simply copy over the old Jenkins data directory to the new installation's location, and then changing the permissions in that directory.
That is to say, the directory containing the config, plugin and job information (it may be something like /usr/lib/jenkins, but could vary).
Then, chown -R the data directory using the user:group info you want to use so Jenkins has access to the files.
I have used this type of method in the past to transfer all the data from one install to another totally separate install on the same box, and it has worked well (one could use this method to transfer the data to an install on another box, as well).
Note: I would highly recommend making a full backup of the data directory before doing this, in case anything goes awry.
So I have been given the task of upgrading one of our companies' old websites that is based on 1.5 to something newer (because a second site of ours on the same version just got hacked).
I know some php and some other web stuff, but I'd never used Joomla.
I have setup a lamp server on a local VM (ubuntu) for me to test it all out on, then upload the upgraded version as is suggested. My problem now is that I know the permissions are not correct because when I tried installing Akeeba Backup, it kept throwing errors such as "could not copy to /var/www/components and /var/www/administrator etc. I went in and chmod'd those 2 (and then the rest of www because of more errors) to 757 (from 755 for the most part) - which i know at that point might as well be 777. Then when I've tried to use Kickstart to restore from the JPA file I have, it just right away throws an error "could not create j_backup/ folder".
I know this slackening of all permissions on the root folder is wrong, but it was the only way to get it to 'work', which it's not even now, so my question is what did I do wrong in the setup and how do i fix it? I'm not great with Linux, but I'm thinking I have to make PHP owner of www? is that right? or terrible practice?
The other issue I see now is that I just installed the latest php and everything and I see Akeepa says not to use php 5.4... not sure how much of a problem that's going to be....
Some direction would be great because I'm more than a little lost.
Thanks!
This is certainly a headache. Most often, as you stated, the issue is the ownership of the files on your server. Files uploaded via FTP will be owned by your FTP user and may not be editable by the Apache/PHP user. Similarly, files created by installing extensions in Joomla! will be owned by the Apache/PHP user and your FTP user will not be able to modify them. Here is an article discussing the problem with a couple of possible solutions:
http://docs.joomla.org/Why_can%27t_you_install_any_extensions%3F#File_ownership_advice_from_ianmac
In the past, I have used an Apache Module called suPHP (http://www.suphp.org/Home.html) to solve this problem and keep it from reoccurring. suPHP executes PHP scripts with the permissions of their owners.
As for file permissions other than ownership, please refer to the Joomla! documentation for the correct settings: http://docs.joomla.org/Verifying_permissions. One quick way to handle this (if you can install extensions after correcting the ownership issue) is to use the AdminTools extension (http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/14087). One of its tools ‘fixes’ the file permissions on your server by resetting them to the Joomla! default.
Good luck!
I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:
[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo
Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.
Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?
Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:
System.getProperty("user.home");
Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.
Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.
Update
The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...
The issue: So how does Java play into all of this? Well, Java
developers sometimes want to store settings for their applications in
a folder within the user’s profile directory. It’s the Linux way, and
Java tends to do things the Linux way. (As mentioned earlier, Windows’
“AppData” folder servers the same purpose, with some extra separation
for data dependent on whether or not it should roam with the user’s
profile.) For some reason, Java does not use the Windows environment
variable to determine the location of the user’s profile, but instead
access a registry key that references the user’s desktop folder. It
then takes the parent directory of the desktop and assumes that is the
user’s profile folder (assuming the user makes use of the default
setup Windows chooses).
Essentially, when a programmer calls the Java command:
System.getProperty("user.home");
Java uses the following idea to determine where my user profile folder
is:
PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"
This breaks down when the desktop folder has been modified.
So, with my setup, instead of saving settings at:
c:\users\tim\
Java apps tend to save data to:
t:\tim\
In reality, Java apps should save settings to:
c:\users\tim\AppData\Roaming\
or something like that.
To add insult to injury, the Java apps continue to follow the Linux
way and use a period at the beginning of the folder name in an attempt
to “hide” the folder (as is done on Linux). For Windows users, this
simply ensures these folders are listed first in directory listings.
(Hiding a folder on Windows is achieved through setting the hidden
attribute for the file.)
It looks like NetBeans has addressed the issue for their application,
but the root issue remains an unresolved, low priority bug. Somehow
I’d bet it would get fixed a lot faster if the mechanism for
determining the user’s home path on Linux was wrong.
I am working on a WinForm application, that allows working to work with "projects" (think about the application as Visual Studio, and projects as VS Solutions).
My question is - where should the application keep its logging files?
Some requirements include:
the application might not be running as an administrator (so saving in the %ProgramFiles% installation folder is not a good option)
The logs should be accessible to end-users (either for review, or for sending to the support team). (This means that hard to find folders, like %AppData%\Company\Application\Version\ProjectName... are not a good solution either)
The application might generate logs even when there are no open projects (so saving the logs in the project's folder is good only when there's a project, but not a final solution).
I was thinking of creating a "working folder" when the application is installed - something along the lines of C:\Application\, and then save the logs in a subfolder, like %WorkingFolder%\Logs\ProjectName
Thanks for the input.
Somewhere in the user's directory is actually the correct place to store them if they are specific to the current running user.
Some programs create folders at the top level of the User's directory, next to Documents and Desktop, others do it in Documents.
Creating it in C:\ might cause issues if the user doesn't have write access to the root directory. You can pretty much guarantee the user will have write access to the Home directory.
The other option is to look for an environment variable, and if its set use the value as the location, if not default to the User's home directory.
If the logs are user only you should store them at %AppData%\Company\Application Name.
If the logs are shared (any user can see any log) you should store them at:
%ProgramData%\Company\Application Name (for Vista+)
or
%AllUsersProfile%\Application Data\Company\Application Name (for XP-)
As for user access, you can add a shortcut to the start menu to the appropriate location or have a link within the program.
Another option in Vista+ is the Public folder (%Public%) which has links throughout Explorer for easy access to.
Where should I write program data instead of Program Files is a good blog entry by Chris Jackson from Microsoft. While it isn't an "official stance" it holds some excellent information.
You can always ask the user to configure this. Set a default path, maybe the application directory. During installation or while setting up the application you may prompt the user to input the path they want to use for logs. That's fair, right. If they're advanced enough to use logs they're good enough to configure a path too.
What do you plan to do with the logs. Are they technical, of for financial/security audits?
The EventLog is a nice place for technical logs, because you can access it remotely (within the Domain) and it is cleaned up automatically.
The %AppData% is also a good place for technical logs, specially if you are unable to connect to the eventlog. You can find the log files, and you can direct the end-user to them, but they are not "in the face" of the end-user. You can include a "send log to the maker" button to receive them.
For logs that needs be accessed by end-users, the My Documents (or a subfolder) looks good.
You can just to add button / menu item to easy open folder with logs.
Best place fo logs are %AppData%\AppName or %temp%\AppName.
Never use %MyDocs% or %Program Files%.
I'd suggest adding that question to the installer so that the user that installs the software can decide where best to put the logs. Though C:\[AppName\ sounds like a reasonable default for your requirements.
Edit: Just thought off, it would probably be worth warning the user if the select a bad location (in Program Files or in the root of the system drive etc) and if they choose to create a new directory, automatically give that directory correct permissions during the installation.
I think %APPDATA%\YourCompanyName\YourAppName is the preferred location. To overcome your stated objection of this location being hard to find, you could pretty easily and quickly implement a simple support screen in your app to allow the end user the ability to access and email these logs without too much trouble, so that the user will not have to remember or manually navigate to the long path name to get to the logs.
I don't really like the idea of the user being able to set this location via the installer because of possible naming and permission issues.
If the app needs to maintain the log only for the users current logged in timespan, then you could keep it in c:/temp.
Most of my winapps, i leave it there, so automatically it gets deleted once the user logs off..
Ofcourse, this primarily depends on your requirement.
I have installed SFTP on a windows servers using copSSH and all is good and it works well
however you can go back from the main root.
For example when i use C:\copSSH\home{username} as that user i can go back into copSSH and into them directories too.
And I have a user setup to actually be C:\inetpub\wwwroot but that user can go into the system and everything i have this set as my path /cygdrive/c/inetpub/wwwroot
It would be ideal if the user could only go forward from the start directory, rather than out and about there is no write ability but there is read and download....... now for the tags ????
Please make sure the user only has access to "home{username}" folder, and does not have any access to other folders.