We're starting development and are at a point where we need a bug tracking site. Our code is in SVN and we're thinking of using Bugzilla, but setup is tricky. I'm considering going for Trac instead. From what I understand, Trac would need to be on the same machine as SVN.
I'm really having a hard time parsing through the Trac documentation. What kind of things should I look for when I'll be migrating?
You are correct that Trac must be running on the same machine as the svn repository; it requires local access to the repo.
To use Trac, you need to: install the Trac software, create a Trac environment, configure your webserver, configure Trac authentication and users, customize Trac as needed for your purposes.
To install Trac, you can use the egg, rpm, or your distro's packaging system, etc.
To create your Trac environment, you will run
trac /path/to/new/trac/environment initenv
and follow the prompts. Since you have an existing svn repo, you will specify the path to it at that prompt.
To configure your webserver, you'll need to decide among several options. I tend to use mod_python though others will direct you to mod_wsgi.
I would recommend installing the AccountManagerPlugin and using its "form based login" instead of http auth. Using it with its htpasswd backend works well; you'd point it to an htpasswd file you create with an admin user and a good password. Then you would grant that admin account full access to the Trac environment like this:
trac /path/to/new/trac/environment permission add admin TRAC_ADMIN
You should now be able to log into Trac with your web browser as your admin user and customize Trac as desired.
Also, #trac on freenode is a good resource for getting help.
Disclosure: I'm one of the Trac devs.
Related
I set up a local Trac wiki using a conda env, where I installed all dependencies, except the system packages, which I installed in the system:
trac-admin . initenv
I entered the required infos like project name there.
Then I run the Trac standalone server.
tracd --port 8000 .
inside the directory, where I set up the wiki.
Since this is supposed to be a wiki, which I use locally myself and not for any multiuser setup, I don't need any authentication functionality. How can I deactivate any authentication or need for login for Trac?
I know that I don't have permissions, because I used the quick search field for a page, which could not exist and when the wiki showed no results, it didn't offer a create page button of any kind. According to the StartPage, this means I don't have permissions.
I couldn't find any enable/disable setting for this in the ./conf/trac.ini to do this. It would also be acceptable to find an easy way to create a user, as which I login to Trac, but all the guides from Trac documentation assume prior knowledge of some kind of configuration files and they don't explain those exactly. For example here. Where does that configuration file even go and what kind of syntax does this use? Not really helpful.
You are correct that you need to modify the permissions (authorization). The permissions are stored in the database rather than trac.ini. You need to grant permission using trac-admin utility. See TracPermissions.
trac-admin $env permission add anonymous WIKI_CREATE WIKI_MODIFY WIKI_DELETE WIKI_RENAME
For help, execute:
trac-admin $env permission help
If you wish to setup authentication, see TracStandalone: UsingAuthentication.
We in our team are planning to use gerrit. So, to get introduced, I did set up a server, used open-id for authentication and created some test-users and test-projects in it.
Now we are ready to use it. But we actually prefer LDAP for real use.
So, can I change my authentication system from open-id from LDAP? What will happen to current users then?
I want to clear test projects and changes. How can I do them?
Can I complete delete existing gerrit setup and initiate a fresh setup in same machine? (I tried extracting the jar in different folder, but I faced some problems in it)
I am using Ubuntu 12.04 as my server.
Please help.
Delete the database (you're not using the H2 database anymore, but some MySQL or PostgreSQL server, don't you?) plus the directory where Gerrit is running (the -d parameter, see docs). Additionally, remove the git repos, if you configured them to be located on a different path.
Then all your data is gone and you can start from scratch.
Currently, I can push my repositories to CentOS server (example.com) through ssh to /var/lib/mercurial-server/repos/SOMEREPO using hgadmin.
Is there a way to access SOMEREPO via example.com/SOMEREPO ?
There are a lot of ways how you can publish your repositories.
If you're familiar with apache, the probably simplest solution is to use hgweb.cgi which is a cgi script that comes with the mercurial distribution.
An in-depth step-by-step guide how to setup hgweb can be found at the mercurial wiki . Since you mentioned CentOS, you probably want to check out the hgweb setup guide for RHEL4.
If you're looking for more complete web-based tools to manage your repositories you may want to look into SCM-Manager or RhodeCode.
I'm trying to convince the higher-ups at my work place to migrate to Apache Ivy. I've managed to get a few sandbox projects working using Ivy to power the build, and now I have a greenlight to put together a migration proposal.
We all agree on one thing: we don't want to trust JARs that are located in public directories! I know, I know, a bit paranoid, yes. But we'd like to have a setup where we pull a JAR from a trusted source (either downloading it from the open source project itself, or most likely, gulp, a public repo), and use it for some time before we "certify" it (give it our blessing as a safe artifact to use).
Then we want to have a common repository for all JARs used by our many projects.
My original thinking was to place this repository up in version control (we have an SVN server). But I wasn't sure what best practices dictate. It might make more sense to put our JARs on a file server and FTP to them in the Ivy script.
Either way, SVN (HTTPS) or FTP, all of our servers are authenticated. So, a small number of questions:
Where should we be publishing all of our "certified" JARs (everything from `log4j` to any homegrown JARs we produce)? What do best practices dictate?
The "ivyrep" resolver-type does not take username or passwd atrributes. If our "JAR server" (FTP, SVN, etc.) is authenticated, how do I configure the Ivy scripts to login?
I must echo Brian's recommendation to use a repository manager like Nexus. It's a lot less work in the long run. You'll also discover that the professional version of Nexus enables you to create approval processes around repositories which you plan to use in your build. See the procurement suite functionality.
If, on the other hand, you are determined to build your own repository, then ivy has the tools for the job. You need to become very familiar with the ivy settings file and how it declares and uses resolvers.
If repository is accessible via HTTPS the the url resolver should be able to access it. The resolver will assume that each version of an artifact is in a different directory and you'll need to specify the URL pattern that ivy will need to use when accessing the repository:
<url name="two-patterns-example">
<ivy pattern="http://ivyrep.mycompany.com/[module]/[revision]/ivy-[revision].xml" />
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
The pattern is fully flexible to how you store the artifacts.
Authentication is also handled in the settings file using the credentials tag.
Finally, the FTP protocol is also supported. It's hard to find in the doco, but it's supported by the vfs resolver.
I think that's enough information on an option I don't recommend :-) Having said that I once created an FTP based repository for managing releases to clients. It's useful to have a tool this powerful :-)
Why not use something like Sonatype's Nexus. I've seen it used for Maven, and I believe it'll work for Ivy.
You can set it up to download from remote repositories into (say) a 'test' repository. You can then evaluate those .jars, and if they're good, upload them into an 'approved' repository for general consumption. There's some authentication surrounding this, but you'd have to evaluate that in greater depth. Certainly you can restrict the uploading into repositories via a username/password pair.
TortoiseHg web server configuration has an "Allow Push" parameter where I put the users allowed to push changes. But when I try to push I get an "authorization failed" error. How are the users authenticated? Where do the passwords come from?
Setting allow_push = * will allow anybody to push to your repository served with hg serve. You should of course only do that on a trusted network. Apart from that, you cannot do authentication with hg serve -- you need a webserver in front of it that will authenticate users.
Please see hgrc for a terse explanation of allow_push and the wiki for a slightly longer explanation about what hg serve is for.
I'm just getting into Mercurial, and from what I can tell (and read in the documentation), the TortoiseHg web server isn't meant to be a permanent solution. The docs seem to steer you towards running either Apache or lighttpd.
You may also want to check out Vampire Basic's tutorial on running Mercurial on Windows.
I believe you can just edit your hgrc file, under the [authorize] section:
Store password in TortoiseHg