I'm somewhat new to Trac.
I'm running trac version 0.11.7 on an ubuntu system.
I'm trying to create another project via the following command:
"trac-admin /var/lib/trac/shipping_tracker initenv".
After answering the various questions, the program fails and returns an error
( see: http://pastebin.com/yijzpB3i ) "Table 'system' already exists"
Does this mean that every-time I need to create a new project, I'll have to go into
the mysql database and create a new database, like trac1, trac2, etc??
I did notice this particular ticket ( http://trac.edgewall.org/ticket/5138 ) where
someone states you have to create a new database for each project. Is this correct??
Thank you.
--Mike
Every Trac environment, being a completely self-contained space, uses a separate database. So yes, you need to create a new database for each environment (although it might be a bad idea to name them trac1, trac2 etc.).
If you want to create new environments often, what you really need is probably multi-project support, which allows you to have different projects within one environment. However, it is still not done as of Trac 0.13, and is planned for 0.14.
You might also want to read about various ideas on having multiple projects with Trac. One of them deals with making Trac store multiple environments in a single database, though it might be outdated and probably breaks automatic updates.
I am using Trac 1.0, running as a stand-alone server, and in order to run multiple projects on one trac installation you still need to set up new environment using
trac-admin /path/to/trac/yournewpoject initenv
... then create .htpasswd file in the /path/to/trac/yournewpoject dir, add users using
htpasswd /path/to/trac/yournewpoject/.htpasswd newuser
(or copy an existing .htpasswd file there) ... and then restart trac with similar to the followin command:
python /path/to/tracd --user=yourlinuxuser --group=yourlinuxgroup -d \
-b hostname -p 8000 \
--basic-auth=oldproject,/path/to/trac/oldproject/.htpasswd,realmname \
--basic-auth=yournewpoject,/path/to/trac/yournewpoject/.htpasswd,realmname \
/path/to/trac/oldproject \
/path/to/trac/yournewpoject
This is valid in case you are using the same type of basic authentication as I do.
Related
Is it possible to delete old builds in Gitlab CI?
I tested a few things and have now about 20 builds that are useless (most are failed anyway).
It also shows stages that I don't have anymore which kinda clutters the Pipelines page and some of the uploaded artifacts are a bit big.
I wasn't able to find any documentation on this, only that disabling CI in the settings doesn't remove the builds.
Using Gitlab 8.10 Community (hosted by Gitlab.com)
There is currently no option in the GUI to completely get rid of a build other than expunge related data from the build. (The erase option in the build)
If you would have a local installation you could modify the database directly but I would advise caution. (I'll put the guide here for completeness sake)
Login to the GitLab database. If you use the default PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
Check if there is a table ci_builds. For pSQL: \dt
Delete the builds with normal SQL. For example: DELETE FROM ci_builds WHERE id = 2
(Optional) If you want to cleanup a list of commits which triggered a build you need to midify the table ci_commits.
I am using https://bitnami.com/stack/mediawiki which "one-click installs" a mediawiki stack on my MacBook. This means I can point my browser to http://localhost:8080/mediawiki/Main_Page and create my wiki from that page (which I did, putting several months of neuroscience research work into this wiki).
I upgraded Mavericks -> Yosemite, and it no longer worked.
Bitnami fixed their stack; upgrading /Applications/mediawiki-1.23.3-0 -> /Applications/mediawiki-1.23.6-0 gives me a fresh Wiki.
But how to transfer all my old wiki across?
This is what the filesystems look like:
pi#piBookAir.local ~ /etc:
⤐ ls /Applications/mediawiki-1.23.3-0/
README.txt apps common img manager-osx.app php scripts uninstall.app
apache2 changelog.txt ctlscript.sh licenses mysql properties.ini sqlite use_mediawiki
(mediawiki-1.23.6-0 has identical structure)
I attempt to find where my user data is being kept:
pi#piBookAir.local ~ /etc:
⤐ sudo find /Applications/ -iname "*dendrite*"
/Applications//mediawiki-1.23.3-0/apps/mediawiki/htdocs/images/1/1d/2014_--_Regulatory_mechanisms_underlying_the_differential_growth_of_dendrites_and_axons.pdf
/Applications//mediawiki-1.23.3-0/apps/mediawiki/htdocs/images/f/f0/2002_--_Axon-_or_dendrite-predominant_outgrowth_induced_by_constituents_from_Ashwagandha.pdf
ok, that is finding a couple of PDF-s I added into the wiki as resources.
So I've attempted to overwrite:
mediawiki-1.23.6-0//apps/mediawiki/htdocs/*
with:
mediawiki-1.23.3-0//apps/mediawiki/htdocs/*
And making the following modifications to mediawiki-1.23.6-0//apps/mediawiki/htdocs/LocalSettings.php :
## Database settings (old x.3 version)
$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "bitnami_mediawiki";
$wgDBuser = "bitnami";
$wgDBpassword = "d77297bcc6";
## (new x.6 version):
## $wgDBtype = "mysql";
## $wgDBserver = "localhost:3306";
## $wgDBname = "bitnami_mediawiki";
## $wgDBuser = "bitnami";
## $wgDBpassword = "ed5e8d6e1c";
i.e. Using the old settings
Also replacing "1.23.3" -> "1.23.6" everywhere.
However, this doesn't work. If I keep the new password it does produce a standard empty wiki page. With the old password no page loads, there is an error.
I also tried posting on the Bitnami forum: https://community.bitnami.com/t/transfer-wiki-from-1-23-3-to-1-23-5/26629 but can't see how to implement the reply.
How can I transfer my wiki, short of having to reinstall Mavericks + mediawiki-1.23.3-0, make a backup of the wiki, and then upgrade again to Yosemite + mediawiki-1.23.6-0 and restore from this backup?
EDIT: here is the complete 1.23.3 file structure (that somehow contains my original wiki data: http://www.pasteall.org/55429)
No, please don't overwrite the whole installation directory: mixing code of different releases is bound to cause problems, such as the blank page you get.
There are just two things you really need to "move" from one wiki to the other, database and configuration.
Assuming the new wiki is on the same host, just move your LocalSettings.php and the images/ directory from the old location to the new. Files will be in place and the new install will be able to access all your data from the same database with the correct credentials.
Then just delete the old installation directory (I assume you have made a backup before starting all this, as per upgrading instructions). Normally, one would first delete everything and put the new code in the same installation path.
Instead of keeping the same configuration, it seems you changed IP:port of the database, as well as the password, but kept the same database name. I doubt that can be right.
There are a couple of ways:
Dump your DB from the old version and import to the new DB that you'll be using.
mysqldump -h hostname -u userid --password --default-character-set=whatever dbname > backup.sql
Export your Wiki to XML and then import it.
"To create an XML dump, use the command-line tool dumpBackup.php, located in the maintenance directory of your MediaWiki installation. See Manual:dumpBackup.php for more details."
http://www.mediawiki.org/wiki/Manual:DumpBackup.php
I'm trying to get my project running on Dancer (perl 5.16.3 and centos 5.10), and so far it was pleasant experience - until I tried to deploy it on server.
I've decided to do the simplest thing and run it as CGI app with help
of default dispatch.cgi script from Dancer distribution.
I used default apache settings from Dancer::Deployment manual, but
something went wrong. After a day of struggle with half-working
project I deduced the following strange thing: while running through
dispatch.cgi, my project is able to read from sqlite database, but it
cannot write into database, so Dancer::Session::DBI was not working
properly and hence the problems.
If I run the project with stand-alone app.pl or with
plackup -E production -p 80 bin/app.pl
it works fine and able to insert data into DB. I've tried to change
permissions to 0666 on sqlite db file, but it didn't help.
So why there's a problem with sqlite while running as CGI, and how to fix this?
Well, it was permissions problem, but not for the dbase file - for directory contained that file!
Apparently, sqlite creates some temp files while updating bases.
Beware.
I've installed Trac .10.5, configured the trac.htpasswd file, and am able to log in and view/create tickets.
The problem is that I am currently unable to administer ticket components such as the versions that appear in the drop list on New Ticket.
From command line, I issued the following command:
trac-admin /foo/bar/trac/ permission add myusername TRAC_ADMIN
User "myusername" is listed in /foo/bar/trac/conf/trac.htpasswd, and I am able to successfully log in with that account.
Is there another step I'm missing in order to get access to a system configuration area? (for instance, setting up version numbers)
EDIT:
I discovered that version .10.* and below do not have web admin capabilities installed by default. http://trac.edgewall.org/wiki/WebAdmin
I downloaded the plugin source:
svn export http://svn.edgewall.com/repos/trac/plugins/0.10/webadmin/
Then ran setup.py, which generated a dist/TracWebAdmin-0.1.2dev-py2.6.egg file.
I then issued
easy_install TracWebAdmin-0.1.2dev-py2.6.egg.
Here's the output:
Processing TracWebAdmin-0.1.2dev-py2.6.egg
removing '/usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg' (and everything under it)
creating /usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg
Extracting TracWebAdmin-0.1.2dev-py2.6.egg to /usr/lib/python2.6/site-packages
TracWebAdmin 0.1.2dev is already the active version in easy-install.pth
Installed /usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg
Processing dependencies for TracWebAdmin==0.1.2dev
Finished processing dependencies for TracWebAdmin==0.1.2dev
My trac/conf/trac.ini file has this section:
[components]
webadmin.* = enabled
I restarted the httpd server (trac uses Apache), and still have no Admin button.
Help greatly appreciated.
You're a bit too hastily seeking advice. Quoting my recent replies to trac-users mailing-list here:
This is most probably a permission issue and will continue with any more
recent Trac environment. Do something like
trac-admin permission add TRAC_ADMIN
to grant full permission to an admin user account, that is usable for
administration tasks. As known elsewhere, you should create a less
privileged account for your regular work to just use Trac.
But please note: Because you've got Python2.6, go for Trac-1.0, don't dare to use anything before this current stable version for a new project, really. Trac-0.10 has been abandoned long ago and 0.11 is unchanged since 2010 too.
You'll have no luck on almost any issue you may encounter, and you miss
a truck-load of great features that have been introduced. Trac 0.11 had
major API changes in many respects, 0.12 went for full i18n support, if
you care for that, and 1.0 is just on the edge, supporting the new db
access API as well as retaining compatibility code for not-yet-updated
plugins (quite a lot to be honest).
I had a similar issue with 0.11.x (minus the plug-in installation), and it turned out that the user account I was logging into via the shell was not the user account that owned the installation. This meant that the changes I was making did not have the right permissions - it is a requirement that all trac-admin changes are made by the installation owner.
Let's say the user that installed Trac was "jim", and I'd logged in as "bob" to use trac-admin in interactive mode. Reapplying a pre-existing permission to a will cause Python to throw an error and kick you off trac-admin. You have to remove the permission first, then reapply it as the other shell user.
The solution was to:
log back in as "bob" via the shell (e.g. "ssh -l bob trac.url.com")
trac-admin path/to/my/project
permission remove TRAC_ADMIN
exit (trac-admin)
exit (ssh)
log in as "jim" via the shell (e.g. "ssh -l jim trac.url.com")
trac-admin path/to/my/project
permission add TRAC_ADMIN
exit (trac-admin)
exit (ssh)
Now when you log into Trac as via a web browser, hopefully you should see the Admin button top right.
I figured I would check out fossil for some small apps I have to complete. I am not new to DVCS as I have used CVS, subversion, mercurial, and git. After installing on my Mac (10.7), using homebrew, I am left with the following when attempting to run:
-> % fossil new ../FOSSIL/project.fossil
fossil: SQLITE_CONSTRAINT: abort at 20 in [INSERT INTO user(login,pw,cap,info) VALUES('developer','','dei','Dev');]: column login is not unique
fossil: column login is not unique
INSERT INTO user(login,pw,cap,info) VALUES('anonymous',hex(randomblob(8)),'hmncz','Anon');INSERT INTO user(login,pw,cap,info) VALUES('nobody','','gjor','Nobody');INSERT INTO user(login,pw,cap,info) VALUES('developer','','dei','Dev');INSERT INTO user(login,pw,cap,info) VALUES('reader','','kptw','Reader');
If you have recently updated your fossil executable, you might need to run "fossil all rebuild" to bring the repository schemas up to date.
I have attempted to run fossil init ../FOSSIL/project.fossil as well as fossil clone http://www.fossil-scm.org/ myclone.fossil which yields the same results as seen above.
I then tried fossil user list as it looks like fossil is having issues with logins and users, however fossil expects a repo argument. Searching for the default configuration (something like ~/.gitconfig with git) yielded no results.
I have also tried rm -rf ~/.fossil and re-running the above commands as well as using brew install sqlite to get the updated version (3.7.7 as of this writing), but neither seem to help.
What do I need to do in order to get fossil functioning properly?
Silly question... is your own username on the system "developer"? Since that would clash with the name of one of the auto-created users.
Try doing "fossil init -A admin (filename)" to use a different name ("admin" in my example) for the repository owner and see if it works.