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
Related
I am trying to move Trac data from an old server at my workplace to a new server but I am stuck on the last step of migrating our wiki data. We use Trac 1.0.1 and are trying to update to Trac 1.2. The part I am stuck on is dumping the wiki. I have been trying to use
trac-admin wiki dump
This works for my tests but when I try to use it on the actual wiki I get an error saying that the filename is too long. This happens because the hierarchical files try to make a filename like this
child1%2child2%2child3%2child4%2child5%2.....
instead of
child1/child2/child3/child4/child5/.....
Since linux is seeing this path as one name it throws an error saying that the file name is too long. Has anyone ran into this problem before and have a solution for it????
I have also tried making a hotcopy of trac and transfering it but this doesnt work either. If anyone knows where the wikis are stored and how to copy that from our old server to our new server that would be the most optimal solution I am looking for
On Bacula/Bareos, document stress the importance of Catalog bootstrap file must be save on somewhere safe, I know Catalog consist of MySQL DB dump and optional included Bacula/bareos config file, but how exactly does anyone recover from scratch in case the whole backup infrastructure is gone?
Is it just install all Bacula/bareos software, then import MySQL and config then fire up Director would do the trick?
A bit of an old question, but I'll provide some feed back,
If you've done a mysqldump of the database (or pgdump depending on the backend) you essentially have the catalog in it's full state. I believe that you can simply restore this database to a new server, and restore the old config files (these are not stored in the dump but rather in /etc/bareos). Also, make sure that the same user/password is used for the database user as specified in the bareos-dir.conf file, or else you will not be able to connect to the database. Depending on how your storage devices are setup you may need to mess around with the baroes-sd.conf file.
To answer the other question off the OP, you can use a volume without a catalog. It's a bit cumbersome, but is possible with the following:
http://www.bacula.org/5.0.x-manuals/en/utility/utility/Volume_Utility_Tools.html
For example:
List jobs on a volume: bls -j -V Full_1-1886 FileStorage1
List files on a volume: bls -V Full_1-1886 FileStorage1
Once you have found the file, or directory (Note wildcard characters are supported) you can extract the file:
bextract -i restoreFiles -V Full_2-1277 FileStorage2 /tmp/
Where:
restoreFiles specifies a file separated with newlines that lists files/directories to restore
/tmp/ is the destination of the restore
I would like to run a local Monticello HTTP repository at work, so that we can share code easily among colleagues.
Is there a way to run something similar to SmalltalkHub privately?
EDIT:
I have tried all the options here and neither of them seems to work smoothly. Let me recap the options:
1) WebDAV on Apache, following Stuart. I have tried it, following some online guides. My current dav.conf looks like this:
DavLockDB /tmp/DavLock
Alias /pharo /opt/data/pharo
<Location /pharo>
Order Allow,Deny
Allow from all
Options Indexes MultiViews
Dav On
AuthType None
</Location>
I worked for a few days. Then suddenly I am not able to read new versions of a certain package. Whenever I write a version in an image and read it in another one, I get an exception ZnInvalidUTF8. I am not sure why, it may be that WebDAV has issues listing too many files?
2) Setting up my FTP. It seems to work, but when I try to set this repository as a remote in the versionner I get MCFtpRepository doesNotUnderstnd: #koRemote
3) SqueakSource3, following Tobias. I have tried running the two Gofer commands in both Pharo2 and Pharo3. In Pharo2 it does not load at all. In Pharo3, more or less everything works. I had to fix a few errors due to deprecated or removed messages, but in the end I am able to create projects and write to them.
The problem arises when I read. Apparently SS3 keeps some kind of internal cache. The result is that the list of packages I see on the project page is different from the list of packages that the client gets. The difference seems to be that the client requires a short version of the page, like http://localhost:8080/ss/MyProject/?C=M;O%3DD, and the results there are consistently less than in the full page http://localhost:8080/ss/MyProject.
Moreover, even on the project page, the list of versions remains cached until I navigate on a different project.
4) SmallTalkHub, following Sean. I have tried both using images from the INRIA server and images suggested from the Pharo-VM-loader (they may be the same).
I had to install Seaside again, since there was no ZnZincAdaptor in the downloaded image. I am now able to start SmallTalkHub, but as soon as I try to register a user, I get an error MessageNotUnderstood: receiver of "new" is nil. I am not able to track where this error comes from (is there a way to open a server-side debugger instead of returing 500 in Seaside?).
After this error, I can see a user both in mongodb and in the interface, but I am not able to login.
5) Git using filetree, as suggested by Kylon. This would prevent me from using MetaCello to handle dependencies and looks even more compelx than the other options.
At this point I am at a loss. :-( If I want to use Pharo, I will need to be able to collaborate with my colleagues. Using open source repositories is not an option, at least right now.
Is there a simple, tried and tested way to set up such a repository?
SqueakSource3 or SmallTalkHub would be even better, thanks to their user interfaces, but I really need at least basic collboration. Having an option that can run on a headless server would also be a big plus, as if this becomes a tool we use, it will not be doable to host the repository on my laptop.
Per this thread on the Pharo Dev mailing list:
Setting up the Server:
Download a SmalltalkHub image (https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/)
Install mongodb on your computer (for Debian: apt-get install mongodb)
Launch the SmalltalkHub image
Evaluate: ZnZincServerAdaptor startOn: 8080
Visit http://localhost:8080/tools/hub, create an account and a project
In addition to Sean's answer - if you just want a Metacello repository, and don't necessarily need the full SmalltalkHub stuff, then you just need a WebDav server. Apache will work fine, and I've even used Confluence's WebDAV support (with some tweaking) successfully in the past.
In addition to the other answers:
Just storing your versions in DropBox work very well!
You can also install SqueakSource3 (like SmalltalkHub, doesn't need MongoDB):
Gofer new
url:'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
package: 'ConfigurationOfSeaside3';
load.
((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load.
Gofer new
url:'http://www.squeaksource.com/MetacelloRepository';
package: 'ConfigurationOfSqueakSource';
load.
((Smalltalk at: #ConfigurationOfSqueakSource) project version: #bleedingEdge) load: #('All').
Then start your Adaptor (eg ZnZincServerAdaptor startOn: 8080) and goto http://localhost:8080/instalSS
Another way is go down the popular route of Git. I am using Github for my projects and it works great while Git itself works very well locally too. So if are already familiar with Git then its a very good choice
You can find more information here https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/GitAndPharo/GitAndPharo.pier.html
Sorry about the bad smalltalkhub experience. I have made some fixes to the configuration, and need to check if that is enough
I'm following the instructions found here.
When I try to run $ heroku pg:psql or $ heroku pg:psql HEROKU POSTGRESQL_BROWN I recieve the following error message:
! The local psql command could not be located ! For help
installing psql, see local-postgresql
I can't find anything useful on the link it gives me (it just links to the instructions I was already using, but further down the page) nor can I find this error anywhere else.
If I've missed anything you need to know to answer this, just let me know. I'm rather new to all this and teaching myself as I go.
I had same error even after installing Postgres locally.
But after seeing this
I saw that "pqsl" was not in the PATH so I then did
PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin
which worked for me
I have since solved this myself. When I ran heroku pg:info it says the version number is 9.1.8, I was locally running 9.2
installing 9.1.8 and ensuring Path pointed to the appropriate folder solved the problem.
After you change the path, make sure to restart the terminal!
Set the PATH. To find out the PATH of your psql script (on mac) open the sql shell script from your finder in Applications/Postgres installation. This will give you a hint as to where it is installed. That opened a window which told me it is located here: /Library/PostgreSQL/8.4/scripts/runpsql.sh
Then, I set the PATH variable from the terminal window by typing:
$ PATH="/Library/PostgreSQL/8.4/bin:$PATH"
(depends on the location of your PostgreSQL installation, find your bin path first, another exp: /usr/local/Cellar/postgresql#9.6/9.6.8/bin)
OR.....
You can also connect to the shell by opening the shell directly from your postgres installation folder. Then enter the credentials. If you don't know the credentials, here is how to find them out:
$ heroku pg:info
=== HEROKU_POSTGRESQL_RED_URL (DATABASE_URL)
$ heroku pg:credentials HEROKU_POSTGRESQL_RED_URL
Top answer wouldn't work for me oddly, my system would not add the Path via cmd with administrator access (Not sure why).
So check this > Windows key > environment variables > system variables
And add the last line (your version may differ in the path)
Make sure you've installed the toolbelt as psql is installed by default.
However you also need to ensure you've installed a local copy of PostgreSQL; if you don't the toolbelt will be unable to find the native psql client.
Assuming you have installed a local copy of PostgreSQL, make sure you can execute psql from the command line directly (i.e make sure you PATH is set correctly ). If the command does not execute, check your PATH, if it does execute see if you can connect via the PSQL connection string provided in the Heroku control panel. If you can connect reinstall the toolbelt, if you are unable to connect provision another dev database and try again.
If there are still issues, I would suggest contacting Heroku support for assistance after verifying no API issues are listed on the status page located here.
I got rid if this annoying message on Windows by adding a path element without the spaces, i.e.
C:\Progra~1\PostgreSQL\9.4\data
instead of
“C:\Program Files\PostgreSQL\9.4\data”
I followed the instructions here: http://www.computerhope.com/issues/ch000549.htm, which worked for me if you prefer to go the point-and-click configuration of the PATH variable.
This type of error usually appears in the Windows environment, because if you do not update the PATH after installing Postgresql, heroku pg:psql command does not work.
So you need to update your PATH environment variable to add the bin directory of your Postgres installation. The directory will look like this:
C:\Program Files\PostgreSQL\<VERSION>\bin.
For more information, go to the Heroku in Local setup website:
heroku-postgresql: Local setup
I had the same problem and discovered that Heroku doesn't seem to provision the latest version of PostgreSQL by default. Where the Heroku Getting Started instructions said
heroku addons:create heroku-postgresql:hobby-dev
That provisioned a v10 database for some reason (which you can check by clicking on Heroku Postgres in the Add-ons tab of your dashboard). I deleted that database and provisioned a new database using the --version flag:
heroku addons:create heroku-postgresql:hobby-dev --version 11
As of now, at least, you can find the latest version of Postgres supported by Heroku at this link: https://devcenter.heroku.com/articles/heroku-postgresql#version-support-and-legacy-infrastructure
I'm writing this in early 2019, but according to the PostgreSQL website the next version (12) is "tentatively scheduled" for third quarter of 2019 so if you're reading this in late 2019 potentially the same problem will come up for v12 instead
On Mac you can use the following:
export PATH="/Library/PostgreSQL/12/bin/:$PATH"
The only solution that I found on Windows:
go to advanced system settings
go to environment variables
select Path variable and click Edit
add a new line and enter your bin directory path (C:\Program Files\PostgreSQL<version>\bin) and click ok
restart your terminal
enter your psql command (heroku pg:psql)
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.