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
Related
I am trying to configure Gitlab review apps in my Ubuntu 14 server. First I want at least to makes work the example explained here also, installed gitlab runner, and configured one as said here
I have a subdomain pointing to the IP of my server, let's say mysubdomain.domain.com I changed that in the nginx file.
Now, when I open MymergeReq.mysubdomain.domain.com nothing happens, I get: server not found.
If I open subdomain.domain.com I get the Nginx default index page.
My question is, where should I download that repo to make it work? I tried in /usr/share/nginx/html but the same, I think that I am missing some glue in all those things and I cannot find what is.
In the proposed Nginx file, in that tutorial, where they refer to the original place of the repo? or at least the .gitlab-ci.yml file?
The reason MymergeReq.mysubdomain.domain.com isn't working is due to the fact you have not set a wildcard DNS record for *.mysubdomain.domain.com is my guess.
The .gitlab-ci.yml file should be that of your project.
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).
I am tasked with monitoring the changes made to the source files of a website. I am not developing the website, just watching it. I am a firm believer in using version control, and am a fan of git, but the developer who is actually maintaining the site is not, and I have decided it is better to let him continue to work however he wants (don't ask). I do not want to have to give him any instructions whatsoever (except possibly telling him that I am adding files or directories that he can ignore).
I consider myself an intermediate-level user of git, so I want to run this by an expert or two.
I am thinking I can install git on the (Linux) server, and then ask for status, and do commits, via SSH. Will this work without jeopardizing the normal operation of the web server?
Yes, using Git on a server should not interfere with the normal operation of the server (as mentioned in the comments, doing this on a production server is dodgy but I'll leave that to one side.)
Note that using Git normally will create a .git directory at the root of whatever you're tracking. If that is your web server root directory, you might want to consider whether this is a risk as far as external access to the contents of the .git directory (depending on your server setup, this may or may not be a concern).
If you want to create the .git directory somewhere else outside your working tree, see the GIT_DIR environment variable.
I have a web dev. client using a shared host that doesn't allow shell access, and thus no access to SVN, Git, etc. I've tried to convince him to move to one of the many cheap options that allow it, but he won't do it. If I use version control on my staging server, are there any tools that will allow me to replicate the changes to production via ftp? Locally I have both mac & windows, the staging server is linux, so something that works on any of those platforms....
Using your Linux staging server you could keep a separate checked out copy that you use specifically for that host and then use a utility to mirror that directory with the host server.
LFTP is useful for this kind of thing. Its available for most Linux distributions and includes a 'mirror' function:
Mirror specified source directory to
local target directory. If target
directory ends with a slash, the source base name is appended to
target
directory name. Source and/or target can be URLs pointing to
directories.
Some kind of ftp mirror software is what you need. Not tested it but a quick search gave me this Java application. You could run that over your up-to-date checked out repository.
Good thing for keeping SVN repo and FTP copy in sync is svn2web. May I suggest creating separate branch for production copy and do merges to that branch for uploading to production server.
You probably need to write a batch file that is able to
Export the SVN repository
Upload the exported files to your Linux server via FTP
Short of finding / implementing some FUSE based CoW file system that supports immutable versions .. I'd just find another (more developer friendly) host. As far as I know, no FTP server supports this natively, nor can I think of any elegant means of putting it in place with script hackery.
I could be wrong.
This question (and answer) really helped me just now as I implemented version control via gitolite on a separate server and lftp.
Here’s what I did:
Set up gitolite on my ubuntu staging server
created base repo (i.e. foo.git) on staging server
cloned foo.git into working directory on staging server
cloned foo.git into working directory on local development machine
Developed locally
Pushed changes to foo.git repo on staging server
On staging server, logged into working directory, and pulled in changes from foo.git
lftp-ed into shared host (like you mention above)
Once in shared host, ran:
mirror -R --only-newer --delete --parallel=10 /source/directory/ /target/directory
Notes on the mirror command options:
-R - this pushes the source/directory to the target/directory. (mirror pulls in from target to source without this, think reverse)
—only-newer - without this option, even if you only changed one file, the mirror command will send all the files in the source directory over to the target directory. with this option only the changed (newer) files are transferred over the wire.
—delete - deletes files that are no longer in the source directory but still in the target directory. one of my pushes involved deleting expired assets. without this option, the same files would have stayed put on my shared host after executing the mirror command.
—parallel=10 - transfers 10 files at once (instead of 1 by default). this made the process much faster
While this is what worked for me, I’m sure there are ways to improve on this. I was grateful for this question and thought i’d share my experience.
Rsync will do this over an FTP connection. You probably already have it installed if you’re on a Unix-like system.
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?