Securing Git server on windows? - windows

Using msysgit and copssh, is it possible to secure the ssh part such that it can only access the relevant git executables and also be constrained to access only one folder?
I have a feeling that a git server on windows will be very much more open than a svn server like visual svn. I'm hoping to be proved wrong.

I would use a Linux server for your central Git repository. Install gitolite. This will enable you to administer branch rights etc.
UPDATE:
As per your recent comments, just go with unfuddle and be done with it in 1 minute. If you're concerned about using up the 500MB of space they give, large non-private artifacts can be stored as a submodule that can be hosted on github.
hope this helps!

On Windows, I have found Apache and Smart Http ( git-http backend ) to be the best way to host a Git server.
https://web.archive.org/web/20100308035130/http://progit.org/2010/03/04/smart-http.html
And coming to access control, I would advice you to keep it simple and have an access conf file svn or even gitolite / gitosis and write simple hooks in the Git repo ( in Python, Ruby, etc. )
The hooks will provide you pretty good control to the Git repo. You can control checkins per branch, checkins to particular folders etc.
Have a look at the git hooks man page. pre-receive or update are the hooks that you can make use of for this purpose.
Look at this awesome chapter from Pro Git on how to use Git hooks on the server side to enforce policy - https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy
You can easily adjust them and add functionality to suit your purpose.

I would very much recommend using one of the Git-HTTP projects.
See my answer at: https://serverfault.com/questions/58425/setting-up-git-repository-on-remote-windows-server/163065#163065
You're trying to make Windows behave like UNIX.
Better go with the flow, and use a .NET based solution as Git server backend.
When you have the deal with a small 2-person project (as you mentioned in the comments), you can also host the git repository on a Windows network share. It just works, and you clone the UNC path (or mapped drive letter) in your git client.
For UNC paths, when you use slashes instead of backslashes (i.e. //server01/git/myrepos.git).

An alternative might be to use https://github.com/jakubgarfield/Bonobo-Git-Server/wiki

When I started looking at setting up a corporate git service, we have the following requirements:
1. Manage git repositories as projects, where we can provide self-service access control at project level.
2. LDAP login integration
3. Low administrative effort
I evaluated vanilla git, git + git-http, gitolite. These solution would require an admin person to manage the access control. If the team is big, this will be a significant effort. If the team is small (5-10 developers), vanilla git is ok.
I looked at github enterprise, use github, and later bitbucket. We eventually bought bitbucket and have a on-prem version up and running. bitbucket meets all our requirements. In addition, we can selectively sync some of the AD group to bitbucket and manage access at group level.

Related

Using GIT in Plesk for a laravel project

I currently have a web application installed on my 'domain.com'. My server makes use of Plesk. What I then did was copy my app on a subdomain called 'test.domain.com' The second one is what I use for development work and once I have coded and tested, I manually copy the files across to the folders in the 'domain.com' project.
It is a very tedious process and I sometimes loose track of changes. My background is electronics engineering where I did some embedded programming in C. I am familiar with SVN version control and I am aware how version control can make my life easier.
Does anyone know what I can do to implement GIT or other alternatives to simplify my development process?
You can link a git repo on Plesk, and also you can choose the branch you want to pull too.
Link the master to branch to your domain.com root directory and another one like "develop" on you test.domain.com.
Plesk will give you a webhook link you can add on your git repo to auto-pull when you pushed.
You can add some after pull command on plesk, like a schema update for your laravel project too.

Netezza CI/CD tool

Is there any CI/CD tool for Netezza that can manage versions and can be used for migrating code across environments? We have used flywaydb for other databases and are happy with it, but that does not support Netezza. I have already googled and did not find a single tool, so any responses are good for me to begin analyzing further
To my knowledge, there's nothing specifically geared for Netezza. That said, with a bit of understanding of your target environment, it's certainly possible.
We use git and GitHub Enterprise (GHE). The reason for GHE is not particular to this solution, but rather because I work at a hospital. Here's what we do.
Setup
Build a repository at /home/nz on your production server. Depending on how you work nzlogs, nzbads, and other temporary files, you may need to fiddle quite a bit with the .gitignore file. We have dedicated log directories where temporary files should reside.
Push that repo into GHE.
If you have a development server, clone the repo in the /home/nz directory on that server. Clearly you'll lose all development work up until that point and will want to make sure that things like .bashrc are not versioned. Alternatively, you could set up a different branch and repo and try merging the prod and dev versions. We did this, but I'd recommend just wiping your development box with production code one slow day.
Assign your production box a dedicated branch in git. For this discussion, I'll call them prod and dev. Do the same for development, if you have it. This is mainly a mental thing, not a tech thing, but it's crucial, like setting up a remote for Heroku or Azure.
Find or develop a tiny web server that can listen for GitHub webhooks. I built a Sinatra server with a simple configuration file. Anything will do. Deploy the web server to each of the environments and tune them to perform the following activities on an update to the prod or dev branches, respective to the server.
git reset --hard
git clean -f
git pull
Set up webhooks in your GHE repository to send the push event to the web servers.
Of course, you can always have the web server do other things on a branch update if you want to get fancy (maybe update cron from a versioned file or update schemas from all new files).
Process
Fairly simply, follow the GitHub Flow workflow. You can pretty much follow whatever process you want with the understanding that your prod and dev branches should be protected and only removed or futzed with as an admin task. Create a feature branch, test it by pushing to dev, and then make a pull request for the prod branch.
Why GHE? Mainly because it keeps an open area where our code is available. You could absolutely do this by pushing directly to Netezza's git repo, but your workflow will suffer--it just isn't as clean as having all code in one clear place with discussion around pull requests.

Administrating a remote non-bare git repo with a GUI

I've also asked this on reddit, but I'm hedging my bets by asking here as well.
We have an employee who needs to be able to treat a remote non-bare repository as if it's a local one. This employee needs to be able to branch, commit, and merge. There are are a few complications.
Employee is on Windows.
Employee has only surface familiarity with git, and needs to be able to do everything via a friendly GUI.
Employee works from home over a spectacularly flakey internet connection.
I believe that a good solution would involve using sshfs to "localize" the remote repo, allowing any git GUI to treat it as if it's local. But we don't know if this will be compatible with an internet connection that comes and goes periodically, and according to the phase of the moon.
Additionally, the senior engineers would prefer finding a GUI client that has built-in support for administrating remote non-bare repos, rather than doing it with an sshfs "hack". Unfortunately, that would rule out SourceTree, with is the preferred choice of the employee in question.
Really, this is two questions in one:
Is there any reason that sshfs would be unsuitable for a use case with infrequent changes, but a shaky connection?
Are there any git GUI clients for Windows that support this functionality built in?
It looks like we have an alternative solution, that sidesteps the problem entirely with git hooks. I'll just paste in the reddit comment:
It's looking like we're going to end up solving this with git hooks, as follows:
Have bare repos at /srv/git, and non-bare repos in the employee's ~ dir
Employee works in local repo, pushes to remote bare repo
Git hook in remote bare repo does the following:
cd ~name/$repo
git fetch --all
git checkout origin/$branch
Thus, the working dir is always the latest commit of the most recently pushed branch.
For the employee, it's as easy as hitting the "Push" button in SourceTree. All the magic happens on the server.

Starter Questions for Using Git Windows Version with Git Source Control Provider

I was using "Tortoisesvn" to take control of my programs's source code. But sometimes, I had problems/bugs while using it. So I decided to use "git"( http://code.google.com/p/msysgit/ ) Also, I'm using git with "Git Source Control Provider" visual studio plugin. Source control is very easy with this extension.
So now I have few noob questions...
1) Where is the main repository? Where is the folder that my project's files backup?
2) Is this program working completely offline? I mean how secure is that? Are there any changes that someone can steal your files( repository/source codes etc. ) ?
Thanks for any input*
Best Regards,
Git is different from SVN in that Git is a DVCS - Distributed Version Control System. That means every "working copy" is a full blown repo. Repos can talk to themselves and there is no need for a main repository ( but usually there is a main or "blessed" repo that is the central.)
So when you created a Git "working copy", you created a repo. You setup another repo on different maching / server and push to it if needed.
I don't know what you mean by "backup", but the metadate for git will be under the .git folder ( it will be hidden unless you have selected to show hidden files and folders in Explorer)
Another feature of DVCS that results from having full blown repos and no main repos is that it works offline. You get full history and you can commit without contacting any server etc. Again, I don't understand why you would ask about security in this context? If it is offline, wouldn't that be the most secure? And Git has lots of security and integrity mechanisms.
Git doesn't work with a centralized "main" repository. Each repo is considered an equal to every other repo.
Git can work completely offline (unlike some other source control systems), but in order to push changes to other repositories you'll of course need to be connected in some way to the machine where the remote repo is hosted.

Howto add an existing VS project to Mercurial (using TortoiseHG or VirtualHG)

I am new to Mercurial / TortoiseHG / VirtualHG. After reading some tutorials I still fail to understand how it is supposed to work.
Could someone please explain in a few simple steps how I add an existing VS2010 project to Mercurial using TortoiseHG or VirtualHG, and how I go from there?
So after adding it to Mercurial, what do I need to do to start working on this project again? Years ago I have worked with Visual SourceSafe, so maybe this experience confuses me right now.
Also I'd like to know what to do when colleagues want to work on this project.
I see in the comments that you managed to get your source files under version control with:
$ hg init
# (setup .hgignore)
$ hg add
$ hg commit
Great! To share the project with your colleguages you need to make the repository accessible to them somehow. You have three options:
Filesystem access: This is the easiest if you already have a shared network drive setup. You put the repository on the shared drive where everybody can read and write. People make a clone from the drive back to their own machine and work on the files there. They commit there as well and finally use hg push to send their changes back to the repository on the shared drive.
Make sure that everybody uses version 2.0 or later with such a setup! There has been bugs in earlier versions of Mercurial that could cause repository corruption when pushing to a repository on a network drive.
HTTP server: You can use hg serve to start a built-in webserver in Mercurial. The server can be used to clone from. In a trusted environment you can start it as
$ hg serve --config "web.push_ssl=no" --config "web.allow_push=*"
to disable the default security settings and allow anybody to push new changes to the server.
For more heavy-duty use, we recommend setting up a "real" webserver and install the hgweb (Fast)CGI script that comes with Mercurial. See the Mercurial wiki for information on that.
SSH server: This is easy if you have an existing Unix setup where people have SSH login to a central server. You need to install Mercurial on the server and create a repository there that people have read and write access to. This is also covered in the wiki.

Resources