I've installed Bitnami Redmine 2.5.0 stack onto a fresh new Ubuntu 12.0.4 VM. I've imported the old Redmine 1.2.1 db into a new db and finished the job with rake db:migrate RAILS_ENV=production.
Now I can login into the upgraded Redmine with my old user account.
After copying the old svn repo into the new VM I couldn't see the repos. I've checked the project repo settings and found out that the old repo URL file:///home/svn was not the same on the new VM. The new VM's home path is home/user/ which changes the svn path into file:///home/user/svn. The URL box is grayed out when I try to edit the repo settings on the projects. My user on Redmine is an administrator.
Is there a practical way to globally change this path on Redmine (or SVN or Apache ???) or should I change the path settings on Linux? I want to change it globally because we have nearly 130 projects, so it isn't practical to edit the URLs one by one. I'm very inexperienced in Linux and mostly google my problems or ask my coworkers. So please guide me accordingly in simple terms.
I suggest moving your repositories to the same path as on the old machine, this will save you a lot of time and headache.
Redmine is configured to access the repository locally on filesystem (i.e. it does not access Apache HTTP Server); it's not clear how your Apache HTTP Server is configured in regards of the repository located in /home/user/svn. You may need to adjust Apache's configuration (httpd.conf) file to point to the changed repository path.
I was able to change 50+ repositories in one go by executing a simple SQL update query which replaced a part of the url field in the repositories table.
You may have to restart redmine for the changes to take effect (not sure about that).
Related
I am setting up a SSL certificate on my GitLab installation. I am trying to find the root directory to upload a file ( for ssl validation via http ) but I am not sure where is the Gitlab root Dir.
Kindly, point me to where to look or find it?
Directory structure
Omnibus-gitlab uses four different directories.
/opt/gitlab holds application code for GitLab and its dependencies.
/var/opt/gitlab holds application data and configuration files that gitlab-ctl reconfigure writes to.
/etc/gitlab holds configuration files for omnibus-gitlab. These are the only files that you should ever have to edit manually.
/var/log/gitlab contains all log data generated by components of omnibus-gitlab.
Omnibus-gitlab and SELinux
Although omnibus-gitlab runs on systems that have SELinux enabled, it does not use SELinux confinement features:
omnibus-gitlab creates unconfined system users;
omnibus-gitlab services run in an unconfined context.
The correct operation of Git access via SSH depends on the labeling of /var/opt/gitlab/.ssh. If needed you can restore this labeling by running sudo gitlab-ctl reconfigure.
Depending on your platform, gitlab-ctl reconfigure will install SELinux modules required to make GitLab work. These modules are listed in files/gitlab-selinux/README.md.
NSA, if you're reading this, we'd really appreciate it if you could contribute back a SELinux profile for omnibus-gitlab :) Of course, if anyone else is reading this, you're welcome to contribute the SELinux profile too.
Source
Thanks to #Drew Blessing who pointed me to read on omnibus. I end up using a different method for SSL validation so I didnt need to upload a file to the root directory of GitLab.
If I understand correctly, you are trying to place an HTML file so your SSL CA can validate your domain ownership. This will not be possible with the way Nginx is configured within the Omnibus package. All requests are routed to Unicorn (the backend server).
Can you use another method to validate your ownership, such as DNS record, whois contact email, etc?
For GitLab CE Omnibus package, it's /home/gitlab/
For previous stand alone version, it's /home/git/ by default.
I don't know what kind of file you are trying to upload, but usually, people usually do not upload file to gitlab's folder.
SSL cert goes to /etc/ssl/localcerts
Config files are located at /etc/gitlab for Omnibus package
/home/git/gitlab for prev stand alone version
I'd like to do some changes to a modx revo install through a staging subdomain, with a separate database. What's the easiest way of doing this? I've been battling with this for two days.
I'm trying a new install now and replacing content, components and database content
I end up moving/duplicating MODX sites between live and staging subdomains several times per week. Here's how I do it.
MySQL
Create a new blank staging database
Make sure you MySQL user can access the new databse
Export/Backup your live database
Import the backup to your new/staging database
Files
Download the matching version of MODX from http://modx.com/download/previous-releases/ because you'll need the /setup/ directory (hopefully you didn't leave that on your server previously).
Copy the entire content of the 'public_html or 'www' folder over to the staging subdomain folder. Don't forget the .htaccess file which is sometimes hidden.
Upload the setup folder to your staging location on your server just like it would be found in a clean MODX install.
Update the three config.core.php files from the top directory, /connectors/, and /manager/ to update the "MODX_CORE_PATH" to the correct directory for staging.
Update the 'core/config/config.inc.php' file. You'll need to update the database details and every instance of your directory structure to match the new staging location.
Run Setup
Run by going to staging.domain.com/setup
If you get ant errors during setup it probably means that you missed something that needed updating in one of the inc.php files.
It's actually very similar to moving the site from one server to another except duplicating to a subdomain on the same server instead. MODX has instructions for moving to a new server at http://rtfm.modx.com/revolution/2.x/administering-your-site/moving-your-site-to-a-new-server
There is another method to solve this problem.
Create new database & user for your sub site.
There is nice github repo. There you can find MODX install script which runs via cli. You'll get a new installed version of MODX in the end.
Install Vapor package from official repo to your old site. Then run vapor script from it via cli. It creates a new package with your whole site dump (You should check dependencies for xpdo objects in this script. For ex. you can copy all the stuff except users or anything else).
After all copy new package to core/packages at new site and install it.
Dump is ready :)
we have created our repositories on Windows-PC using tortoiseSVN. Now we would like to have on our webserver (Linux-Debian, directory ..../html/, reachable using our domain, user= www-data) a svn-working-copy.
Which steps are to be taken to create a svn-working-directory on our Debian-webserver from our Windows-repository?
Thanks in advance
You need to be running an actual Subversion server (Apache or svnserve), not simply accessing a repository created on a file share via file:///. Once you have that set up, just perform an svn checkout just like you would any other working copy.
I have live website running on MODx Revolution 2.1.3pl. Some days back I had to restore my entire site from backup. This messed up some file ownerships (for packages installed and images uploaded etc.) because in my server PHP runs as 'nobody' user which is different from my cPanel user.
Now I can't change much things on the server(like installing suPHP because its a shared server) and I don't know which all files are created by PHP, I decided to wipe the site clean and perform a clean install. My site has a large number of already published resources which is impossible to be posted into the new site individually.
Is there any way that I can transfer those resources to the new installation?
Why don't you create a mysql dump of your old site (with phpmyadmin or the like) and import this into a new database, which you use to run your new site from?
I've not tried it myself but provisioner seems to do (or at least claim to) what you need.
Here's the situation:
subversion is already installed in the server and I have access to one of the shared accounts in the server (not the root), and this shared hosting account has SSH access.
I want to create a repository where I can commit the PHP files i'm working on, and when I commit it should be viewable in a browser that is why I was thinking of creating the repository folders inside public_html is this a correct way to do this? How about the security of the server? If not what is the correct and proper way to do this?
I would also need help in creating the repository via SSH with Putty. Is there a step-by-step guide online for this?
Server information is as follows:
cat /proc/version - output this:
Linux version 2.6.9-89.0.3.ELsmp (mockbuild#x86-005.build.bos.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-11))
svn --version - output this:
svn, version 1.1.4 (r13838)
compiled Aug 10 2009, 23:17:10
ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
handles 'http' schema
handles 'https' schema
ra_local : Module for accessing a repository on local disk.
handles 'file' schema
ra_svn : Module for accessing a repository using the svn network protocol.
handles 'svn' schema
The correct way to do this is to use a web bridge to SVN, such as websvn or viewsvn (there are several). You can set these up to expose any repository as a website.
As to creating a new repository, see the SVN "Red-Bean" reference at http://svnbook.red-bean.com/
I want to create a repository where I can commit the PHP files i'm working on, and when I commit it should be viewable in a browser.
I'm not sure I understand your question. Do you mean that the repository should execute your PHP, i.e. that your Subversion repository should also be your PHP server? I strongly recommend against it.
A source control repository and an application server are completely different things. They serve different roles; should be accessed by different people (developers vs. end-users); should have different monitoring and SLA policies; different hardware, and whatnot. You also probably don't want every committed change to be automatically deployed to your production environment.
The Red Bean book also has a number of sections on integrating SVN with apache, etc. But before you start working on a solution, you need to define what you're trying to do more thoroughly. What is your usage model?
For example, will you commit to SVN repository via svn+ssh, or via svnserve, etc?
Do you want to see full revisions, history, changesets from the web interface? Or just the head?