I have installed nexus 3 on my server at /mydir/nex/local/lib/nexus. This lays down the normal structure.
So I have my data directory pointed to the default -Dkaraf.data=../sonatype-work/nexus3. I have a mounted file system on /mydir/nex where the data installation lives.
Since the installation is under /mydir/nex, should I create a /mydir/nex/data?
Or is it okay to leave the data on the default location?
I'm always fond of using FHS (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard), which means standard folders. So Nexus is put in /opt/nexus and data will go to /var/(opt)/nexus. Logging goes to /var/log/nexus.
It is ok to leave the data under the application if you like and it is also okey of you put it in another directory, it will not break Nexus in any case.
Related
My company has a nexus installation that grew to a rather huge size on disk, thus I am in the process of cleaning it up. While doing so, I found a directory called storage_full in the sonatype-work/nexus directory, adjacent to the storage folder, which is not listed in the nexus directories documentation. Google finds nothing either. The folder is rather large and seems to be similar to storage in structure.
Questions:
What is the use of this directory?
Can I delete it, or clean it up? I'd rather not use trial and error to find out if it's important as any downtime of the service is unacceptable.
The nexus version is 2.11.2-03, but AFAIK it has been repeatedly updated and was running in the same work directory since about 2011 - could it be that this folder was left over from an older version?
Nexus has never had a directory called "storage_full" as part of it's setup, so I'm not sure what this is. Check to see of the local storage location of any of your repositories has been overridden to point to that location.
I want to create a master repository on our server, from which I can clone a local version onto my computer.
I am using R Studio v0.98.994.
So far, this is what I have tried doing:
Create a folder for the master repository to live in. I do this using 'new project' in R studio, and tell it to make a git repository.
I can then open up another new project, located on my C drive, and use R studio to clone, by telling it to open an existing project and setting the URL as the location of the master project.
However, then when I make changes and commit to my local repository (which works fine) I cannot push to the master repository, I get an error exactly as described in this question: git push fails: `refusing to update checked out branch: refs/heads/master`
So it appears that R Studio creates non-bare repositories?
Now I thought, well okay, I will use git bash to initialise the repository and then connect to that within R studio.
I do so, but cannot then find a way to use that repository in R Studio.
I am very new to Git, so it is entirely probable that this is one of those 'read the instructions' questions, in which case I am very sorry - and could someone possibly point me towards some guidance for this situation? I have spent the better half of a day googling around this error and haven't yet managed to pull together the pieces :( I also apologise; this doesn't feel like a very reproducible question.
It sounds like you are using Windows Git, with a setup on a local Windows machine (C: drive) and a server of some kind, mounted as the S: drive. There's a few things you should be aware of when doing this.
Shared Repositories
If you are intending for multiple people to share the same repository, you want to initiate a shared repository. See the --shared option in git-init for more details. Note that I'm not sure how having your repository on a Windows machine affects the sharing options. If you are just trying to keep your repository in two places, that makes things a lot easier.
Bare Repositories
Separate from the discussion of sharing is the discussion of bare repositories. If you don't intend to ever work with files in the server (i.e. it's just going to be a place to push changes so they are safely stored), you could initialize a bare repository. A bare repository contains the database structure of Git, but does not have the actual files in the directory.
A standard Git repository is a directory with a hidden folder in it named .git. This .git folder contains all the various data structures that Git uses to track changes. A bare repository is essentially a folder containing only the contents of .git.
The good thing about a bare repository is that no one can work in the repository itself (since there is no working directory, just the database). This means that no one could log into S: and edit the repository themselves. Instead, they would have to clone the repository, then push their changes back to the origin. The GitGuys have a good article about why this is ideal.
Note that shared repos and bare repos are not dependent or mutually exclusive. As a general practice, if you are having a "server repo" from which you pull and to which you push, you should have it be bare, regardless of whether the project is shared.
A Non-Shared Workflow
Since it's not clear if you are sharing or not sharing and you're on a Windows environment, which I don't know about from a sharing standpoint, I'm going to give you a simple example. Using git-bash, you should be able to change directories to wherever on S: you have your repositories. Then, use git init with the bare options as described by the link above to initialize a bare repository. Navigate to where you want your repository to live on C:, and then do git clone to get a working copy.
Add a README file or something else so you can do your initial commit, and then commit and do git push origin master to push your changes to the S: repository. Once all that is done, THEN initialize the RStudio Git project. RStudio should defer to your existing configuration, and things should hopefully work.
I love using RStudio for it's built-in integration with version control systems. However with RStudio on Windows is there a way to change the Git protocol from http to ssh or vice versa for a project already under version control without first having to delete and recreate the project?
I might be missing something, but I originally cloned my repo using http which I subsequently found to be a massive pain because every time I want to push project changes to GitHub I have to re-enter my username and password. So I removed the project from version control(Project -> Project Option -> Git/SVN -> Version Control System: none) and then tried to re-add version control hoping to use ssh but it will only allow you to go back to the original protocol you selected when creating the project in the first place.
The only way I have found to change protocol it is to delete the project and then create a new project from GitHub using the correct ssh parameters. I'd really like to be able to change projects version control protocol from http to ssh without deleting and re-cloning first.
Is this possible?
Check out git config and the whole configuration stuff. You can configure several remotes to make the "distributed" aspect of git work.
You can try just copying the whole repository (or just .git/config, keep a copy!) and check what happens with your specific case when you change the configuration. It depends on lots of things that aren't under git's control, like firewall configurations en route, and the configuration on the other end.
For an ASP.NET web application that is packaged and sold to customers for deployment, what would be the best location for a "read me" file with notes about setup and configuration on the target system?
Requirements:
The file should not be accessible by
users of the web application, only
the person doing setup and
configuration.
The file should be
consumable by the MSI installer
program, so that it can be displayed
as part of the setup wizard UI.
The solution should be simple and very
low cost. (I don't want an elaborate
solution for just a simple text
file.)
Some thoughts I have are to copy the file to *App_Data* or to bin as those are protected folders by default, and then pull the file in from one of those locations in the setup program.
The readme should be a separate file that sits beside the MSI on the media you distribute the web app on. This is a standard practice dating from generations ago the dark ages. If you distribute as a download from the web then have a link for the MSI, and a link for the readme.
You could also include the same file into the MSI, but arguably that is the wrong place for it as the user has yet to reach the configuration stage, and unless they print it they won't be able to refer to it later in the MSI process (if you have any configuration steps in the MSI).
Having the instructions available via the web app is also arguably wrong, as the user may have to do some initial configuration in order to reach the page telling them how to configure the app....
So ship the instructions separately to the MSI, and make sure they look okay and are easily readable when printed out. Remember these pointers:
Instructions are not always read
Instructions are not always read at the time of installation
Instructions are not always read by the same person that does the installation
Instructions are not always read from the screen
Instructions are not always read correctly, even when they are simple
Instructions are not always read (I know that is a duplicate of the first point...)
Don't forget to clearly distinguish between pre-install and post-install configuration instructions (even if they are in the same document) - you want to minimize the risk of the end user getting it wrong (which some of them will do no matter how hard you try).
Build the important message into your application. Do it like Apache where it says "this is a new installation of...." and don't allow that screen to go away until they go in and do all the things that you consider important.
This isn't a problem for your installer to solve.
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-