CEDAR
CEDAR HepData JetWeb HepForge HepML

HepForge FAQs

Here are some questions and answers relating to HepForge. Please ask us some more questions to make this document more useful!

Shell account issues

  • How can I set up passwordless SSH key access to HepForge?

    Passwordless SSH access is very desirable, especially if you will be logging in repeatedly or using Subversion via SSH, which results in multiple password requests per operation. There are many guides on the Web to setting up passwordless access, but I often find them confusing, so my effort is below. If you find it confusing, then maybe try these alternative guides:

    Here goes, then: You should run ssh-keygen -t rsa on the machine from which you'll be accessing HepForge: this will make a private and a public key in your local $HOME/.ssh/ directory. You should now copy the public key to your HepForge shell account and append the key to your authorized_hosts file. Here's a quick idea of what your command line session might look like (where the e.g. local$ indicates which machine you're working on):

    local$ ssh-keygen -t
    now enter a keyphrase...or leave it blank if you want
    local$ scp ~/.ssh/id_rsa.pub login.hepforge.org:myrsakey.pub
    enter password
    local$ ssh myname@login.hepforge.org
    enter password
    cedar$ cat myrsakey.pub >> .ssh/authorized_keys
    cedar$ rm myrsakey.pub; exit
    local$ ssh myname@login.hepforge.org
    no need to enter password... if it's worked!

    The major cause of failing SSH keys is wrong permissions on either the local or remote ~/.ssh directories or their contents. If you have problems, try making sure that your home directory, ~/.ssh and its contents are neither world- nor group-writeable. After that, ensure that your private key(s) (e.g. ~/.ssh/id_rsa) and your authorized_keys file are neither world- nor group-writeable or -readable. If that still fails, try running SSH with one, two or three "-v" options for more debugging info, e.g. ssh -vv myname@svn.hepforge.org. The debug output is notoriously unhelpful for rooting out passwordless access problems, though, so this is probably the point where you contact your local sysadmin to get it sorted and let you get back to doing some work!

  • Can I make cron scripts execute as my project's user?

    No, not at the moment. The project user cannot login and doesn't have a valid shell. We're afraid that you'll just have to nominate a project member to be responsible for running project cron jobs at the moment. Please try to be sensible with the frequency and timing of cron jobs - don't run them every other minute, don't run them all at the same time, and (if you can) run them in the middle of the night (for Europeans and Americans, I suppose - we don't have many users in Asia at the moment).

  • Why are you making me use the bash shell?

    You can use any shell you want, as long as it's listed in the /etc/shells file. Traditionally, academia seems to use the csh (C-shell) or its updated modern variant, tcsh. However, this is probably through inertia rather than anything else and having a knowledge of the sh family of shells, in particular the bash shell is probably more widely useful: much of the internals of Linux/*nix systems is based on portable sh-type scripts. The popular autotools build system (which we encourage HEP developers to use for building and installing their Fortran, C and C++ software) is also very sh-oriented.

    In my personal opinion, bash also has a much nicer interactive behaviour than tcsh, but this is hardly the place for a religious war about shell preferences - or else someone will be telling me that zsh is better still :-)

Web space

  • How can I make part of my site private?

    Your project configuration area (/hepforge/projname/project-config) contains files called htpasswd and htgroup, which can be used to define sets of groups and users. You can then make areas of your site password-protected by placing a .htaccess file in the top-level directory of the area you want to be protected, as described in the Apache web server documentation: http://httpd.apache.org/docs/2.0/howto/htaccess.html. Here's an example .htaccess file:

    AuthType Basic
    AuthName "My private place"
    Require valid-user

    Note that you don't have to specify the AuthUserFile or AuthGroupFile explicitly: each project's web configuration already defines these to point at the appropriate files.

    We recomment that you use HepForge's SSL encryption functionality on protected areas of your site: otherwise the login passwords that your users type in will be sent across the internet unencrypted. To use SSL, just replace the http with https in the URL. If you make a link to this private part of your site from a non-private bit, make sure you use a full HTTPS URL rather than just a relative path.

  • Why do I get a security warning when I access HTTPS pages?

    The central idea of SSL certificates, which are used to encrypt HTTPS traffic, is that there must be a "web of trust" between the certificate of a Web site (such as HepForge) and a trusted certificate in your Web browser. By default, Web browsers only contain a few trusted certificates, and the companies that own them charge hefty sums to supply certificates signed by their trusted "root certificate". We don't have the resources to spend lots of money on certificates and, after all, why should it cost so much. So we get our certificates signed by CaCert, a free certificate authority: the security isn't any less valid, it's just not bought from one of the "normal" suppliers.

    The best way to use our HTTPS pages (and to spread the acceptance of CaCert, who are doing a great job) is to import the CaCert root certificate into your Web browser. This is very simple: just go to cacert.org, click on the "Root Certificate" link, and then click on the links for the appropriate certificates. Your browser will ask you to verify that you want to import the certificate, and when you say yes, you'll no longer be troubled by warnings about untrusted root certificates. Yay!

  • Can I host my personal home page on HepForge?

    Yes, though it's not our main purpose, so we won't guarantee any uptime, services, functionality or similar. Actually, we don't guarantee anything anyway, but home pages are particularly low priority! If you've got a HepForge user account (i.e. a shell account rather than just a project htpasswd entry) then you can put Web pages in ~/public\_html and they'll be visible at http://users.hepforge.org/~username/.

Bug tracker and wiki

  • How can I get login access to a tracker and wiki?

    To do this yourself, you will need to have a HepForge user account and be a member of the project whose tracker or wiki you wish to edit. Assuming that those conditions are met, log in to the server using SSH, then use this command:

    htpasswd /hepforge/projconf/projname/htpasswd username

    where projname is the name of the project and username is the web user name you want to use. It's best that you use your shell login name for this, to avoid clashes with other web users.

    If you don't have a shell account with HepForge, you should either ask the project developers to give you a Web access name and password or, if there is one for the project, use the guest account.

  • Why can't I use my shell password to access my project's Trac?

    The password authentication used by the Web server is completely separate from that used by the login shell, so you have to set up your Web password separately (as described above). Maybe we'll get this sorted in future...

  • How do I create or edit tickets / milestones?

    For this, you'll need to use the trac-admin command line program from your HepForge shell account: trac-admin /hepforge/projconf/projname/trac This will give you an interactive prompt from which to control your project. You probably want to type "?" or "help" initially, which will produce a fairly clear summary of available Trac commands. Initially, you should define some "components" for your project, with the "component add" command: these are used to define what part of your project a given ticket will be associated with. Each component has a user name designated as its owner: the owner will be the default person to whom tickets on that component will get assigned.

    You'll now want to set up some user permissions, which is done with the "permission add" command: a list of the available permissions can be obtained by typing "permission list" at the trac-admin prompt. The general permissions modes you're most likely to want to use are TRACADMIN (for general control of all Trac features through the Web interface), ROADMAPADMIN (for milestone administration), WIKIADMIN (for wiki administration), TICKETADMIN and REPORT_ADMIN (hopefully you could guess the function of the last two!) Remember that the user names to which you bind permissions have to match the names defined in your project's htpasswd file. There are two exceptions to this: the generic users "authenticated" and "anonymous". Respectively, these allow you to assign default permissions to site visitors who are, or are not, logged in. Trac permissions management is described in more detail e.g. here.

    Users with the approriate permissions should now be able to create, edit and delete tickets, roadmap milestones, reports and wiki pages via the Web interface, provided they are logged in. Buttons should appear on the editable pages to allow this control.

    Much more info on using Trac is available from Trac's own user guide.

  • How can I allow unregistered users to submit tickets / edit my wiki?

    The recommended way to allow "unknown" users to submit tickets and edit wiki pages is to use trac-admin to create a guest account:

    trac-admin /hepforge/projconf/projname/trac permission add guest TICKET_CREATE TICKET_MODIFY
    trac-admin /hepforge/projconf/projname/trac permission add guest WIKI_CREATE WIKI_MODIFY

    and then add the guest account to the project password file:

    htpasswd /hepforge/projconf/projname/htpasswd guest
    enter a password

    You'll have to put something on your project web page to tell them that the "guest" user, with the password you specified, can be used by any web visitor to contribute anonymously to the project. It is also possible to use the trac-admin commands above to add these permissions to anonymous users, but this causes problems with automated "spamming" of the Trac pages, so isn't advised unless you also use some anti-span procedure: see Trac Hacks for more info.

    Of course, if particular users are submitting a lot of information via the guest account, it's a good idea to actually give them an htpasswd identity of their own!

  • How do I get Trac to send me emails when my tickets are added or modified?

    All new projects are set up with appropriate settings in the trac.ini file for automatic ticket emails to work. All you have to do to get them is to log in to the project's bug track Web area, click on the "Settings" link at the top of the page and enter your name and email address.

  • I have two dependent projects: can I link issues between their copies of Trac?

    Have a look at the InterTrac system - it is supported by our version of Trac.

  • How can I set up a private version of Trac?

    Setting up a private version of Trac is, in principle, just like setting up any CGI script. However, Trac needs the Web server user to be able to write to its database, attachment and log files, which you won't be able to set up by default. To make this work, place your private Trac environment in project-config/privatetrac: this location will have its permissions set as required.

    You will also need to move the trac.cgi script into your public_html directory and edit it to change the value of the TRAC_ENVIRONMENT variable to point at your privatetrac directory. You probably also want to add a .htaccess file to the directory containing your private trac.cgi so that it actually is private: see the Trac and Apache documentation for more details.

Version control

  • How do I use a HepForge project's Subversion repository?

    First, see the documentation in the user guide. If your confusion is about SVN in general rather than HepForge SVN specifically, then the SVN book is your first port of call.

    If you want to use Subversion directly, then you have the choice of using the anonymous read-only system over HTTP or the full read-write system via SSH. To use the full permissions system you will need to have a HepForge shell account and be a registered developer on the relevant project.

    First, anonymous access: you can perform lists, check-outs, updates and other operations which don't modify the repository with a command line like this:

    svn list http://svn.hepforge.org/projname/

    No password or similar is required: it really is that easy :-)

    For developers, you probably want to use something like this for the check-out:

    svn list svn+ssh://svn.hepforge.org/hepforge/svn/projname/trunk
    svn co svn+ssh://svn.hepforge.org/hepforge/svn/projname/trunk localname

    You will probably want to set up an SSH key for your HepForge account if you'll use Subversion a lot: otherwise the repeated password requests get annoying very quickly. There are plenty of guides to setting up an SSH key on the Web, but the basic procedure is described in the FAQ entry below.

  • Why don't you provide a CVS web viewer / pserver?

    Users of HepForge who've been with us from the beginning will remember that we used to provide a CVS web viewer, using the ViewVC script. At the start of 2007 we removed our CVS support since a) ViewVC was very hard to maintain and kept locking up and crashing the Web server b) Subversion provides a much more modern version of CVS, and is so syntactically similar that it's basically a bug-fixed drop-in replacement c) only one user was still using CVS!

    We also used to run a CVS pserver (persistent server), but we dropped this at the same time as ViewVC. In this case the reason was that pserver is insecure and so unsuitable for developer use, and the way that it integrates into the Linux services system would force automated manipulations of the server network service configuration: that scared us. Our workaround was a symlink hack to make the server think that all the repositories were really one location: this was so nasty that we breathed a deep sigh of relief when we got rid of it!

    Subversion is an enormous improvement over CVS and has the added benefit of integrating cleanly into our Trac issue management system, meaning that much of HepForge can be run simply as a Trac front-end: that makes life easier for us.

    So, in conclusion, if you want to run CVS, go ahead, but you'll only be able to access it over SSH, it won't integrate with Trac, and every time you ask us about it, we'll suggest that you move to using SVN :-)

  • Tell me about Subversion, then.

    Subversion is a project designed to provide a centralised version control system with essentially the same interface and VCS model as CVS, but with CVS' fundamental design problems addressed. The list of issues that Subversion addresses can be found on the Subversion home page and includes "atomic" commits, much simpler tagging and branching and (from the admin point of view) much improved network and server integration.

    On HepForge, SVN has the additional benefit of integrating automatically with the Trac bug tracking and wiki system, so you can refer to SVN changesets in bug reports and wiki pages, and can browse the changesets and repository through the Web interface. It's very neat.

    We thoroughly recommend Subversion for use as a CVS replacement. Actually, we're not sure why anyone uses CVS any more.

  • I want a private CVS or Subversion area. How can I do that?

    This is relatively straightforward: in fact, it was a lot harder to set up all the Web viewers and anonymous access that your default repository has! In brief, you should create a private repository in your project's home directory, e.g.

    svnadmin create --fs-type fsfs /hepforge/projname/privatesvn

    The same principle applies to using any other version control system. You will then have to access the repository via SSH. With Subversion, that will mean e.g.

    svn list svn+ssh://svn.hepforge.org/hepforge/home/projname/privatesvn

  • Can I use CVS and Subversion at the same time?

    Not for the same code! Both version control systems use a centralised repository but the formats are very different: CVS cannot read or write to a Subversion repository and vice versa. There is a program (cvs2svn) which can convert CVS repositories to Subversion ones, but since Subversion is intended as a replacement for CVS, you cannot convert in the other direction. (NB. There is also a program called Tailor which will convert between SVN and CVS in both directions, but really, why would you want to?)

  • How can I convert my CVS repository to Subversion?

    To convert a CVS repository to Subversion, you should use the cvs2svn command-line tool. Have a good look through the cvs2svn documentation and FAQ before starting.

    1. Ensure that all check-ins to CVS have been made.
    2. Move your CVS repository to the HepForge server: scp -r mycvsrepo login.hepforge.org: mv mycvsrepo mycvsrepo.bak
    3. On HepForge, delete the root directories of your default Subversion repository, since its existing structure will clash with the output from cvs2svn: svn rm file:///hepforge/svn/myproj/trunk -m "Clearing for cvs2svn"
      svn rm file:///hepforge/svn/myproj/tags -m "Clearing for cvs2svn"
      svn rm file:///hepforge/svn/myproj/branches -m "Clearing for cvs2svn"
    4. Convert the CVS repository into a new Subversion repository "dumpfile" called cvs2svn-dump: cvs2svn --dump-only ~myproj/cvsrepo
    5. Import the dump file into your Subversion repository: svnadmin load /hepforge/svn/myproj < cvs2svn-dump

    That's it! Now try browsing your new Subversion repository online at http://svn.hepforge.org/myproj. Checkouts, commits etc. will work as described elsewhere in this documentation.

  • Do you support other version control systems, like Bazaar?

    We're definitely interested in Bazaar-NG but its design as a decentralised version control system means that there's not so much integration required: you just have to make sure that you can publish bzr branches on your project's Web area. We'd be interested in getting Bazaar repositories integrated with Trac - if you want to trial Bazaar-based VCS on HepForge, please contact us and we'll happily help out.

    The same applies to other version control systems, but we'll consider them on a case by case basis. Other decentralised VCS', like Mercurial, should be very similar to Bazaar, provided that Trac bindings are available.

Valid XHTML 1.0 Strict