Re: [tsc-devel] Moinmoin wiki to Redmine wiki progress

Quintus | Tue, 20 Oct 2015 14:26:36 UTC

Hi xet7,

wow, quite a lot of work that you put in it. Some notes.

Lauri Ojansivu <…x@x…> writes:
> sudo apt-get install ruby-rmagick
> bundle install --without development test rmagick

If you pass --without rmagick, then you shouldn’t install RMagick via
APT instead. This will confuse Redmine probably, because it thinks it
has an RMagick available, but in reality it is another RMagick than the
one it expects. Please either install RMagick via bundler (removing
--without rmagick) and uninstall ruby-rmagick, or do not use RMagick at
all (keeping --without rmagick, and removing ruby-rmagick).

RMagick is crap btw. I am glad that Redmine makes efforts to allow for
alternative ImageMagick bridges, such as the much more memory-friendly
and efficient MiniMagick.

> To get iconv error fixed:
> http://stackoverflow.com/questions/7829886/in-require-no-such-file-to-load-iconv-loaderror
> I added to redmine Gemfile:
> gem "iconv", "~> 1.0.3"

Redmine is actively developed software and that should not have happened
at all. Which Ruby version do you run this on? The post you cited
relates to a really outdated and officially unsupported version of Ruby (1.8),
and Redmine does not support that version (see the Installation page you
cited yourself). You must run Redmine at least on Ruby 1.9, better on a
Ruby version > 2.0, since 1.9 itself is out of support already[1]. If
that bug happens on a recent version of Ruby, please file a bug against
Redmine instead of hotfixing it on our local machine.

To overcome the way-to-old Ruby issue on Debian Wheezy, we have a custom
compiled version of Ruby installed on alexandria:

$ which ruby
/usr/local/ruby/bin/ruby
$ ruby -v
ruby 2.1.4p265 (2014-10-27 revision 48166) [x86_64-linux]

I agree that this needs an update (there have been security fixes for
that series of Ruby if I remember correctly).

> For running Redmine locally, I used:
> bundle exec rails server webrick -e production

Please only use WEBRick locally, it is horribly unperformant and likely
insecure, as it is a pure debugging webserver. For a production setup, a
Rails application is usually deployed on something like Thin or Puma
(add to Gemfile.local for Redmine) as the application server (which is
bound to localhost, i.e. no access from the public Internet), and that
server runs behind an Apache or NGINX HTTP server acting as a reverse
proxy. In other words: Apache/NGINX serves the static files that every
Rails application has (JS, CSS, uploaded files by users, etc.), and only
if it doesn’t find a static file, it delegates the request to the
application server and copies the answer over to its own client
connection. I have done that setup multiple times (with Apache), so it
is rather easy to do for me. For Apache, it is done by use of
mod_rewrite and mod_proxy. This setup takes advantage from the
performance tuning that went in highly engineered servers such as Apache
and NGINX, and allows to properly separate the processes (it is for
example possible to chroot the application server easily and use a
different user than Apache/NGINX, in contrast to most PHP applications
that just run with Apache’s own privileges and access rights). Ruby
application servers are rather unperformant in general also, but this
technique easily allows for adding caching of the application server’s
responses to release it from too high load.

If you want to take a look, Chessboard on alexandria runs with exactly
that setup (Thin as application server, reverse-proxied by Apache, but
no cache employed as our setup does not need it currently).

> For migrating wiki content, I used this page instructions:
> http://ward.vandewege.net/blog/2011/11/migrate-moinmoinwiki-to-redmine/

Beware that Redmine has seen two major releases (2.0 and 3.0) since that
post with APIs changing all around. If it still worked, that’s fairly
nice.

> In the script, I got this error:
> Encoding::CompatibilityError: incompatible encoding regexp match
> (Windows-31J regexp with UTF-8 string)

This is a, if not *the* typical kind of error you get when you try to
run a script written for Ruby 1.8 with Ruby 1.9 or newer. Ruby 1.9 added
a highly advanced encoding system to the Ruby programming language,
whereas 1.8 had no notion of encodings and treated strings the same as
plain old C (as byte sequences), which was bad. As a consequence, since
Ruby 1.9 script writers have to tell the Ruby interpreter which
encodings they expect and want to handle.

> rake redmine:migrate_from_moinmoin RAILS_ENV=production

You can set RAILS_ENV=production in the environment if you don’t want to
pass it to rake or rails all the time.

> So now wiki pages are imported into my local Redmine.

It is possible to remove the migration script afterwards, is it? I don’t
think we should carry a customised version of Redmine around, that’s too
heavy to maintain.

> I have already fixed most of the wiki markup differences in wiki,
> uploaded missing image attachments, and removed some spam pages, but
> there's still some pages to fix.

Redmine does not save images and other uploads into the SQL database,
but into files on the filesystem to my knowledge. If you copy your
Redmine instance around, be aware of this.

> - for that screenshot I changed language to English first, because
> Redmine did originally show interface in mostly Finnish.

Redmine looks at the language that your browser requests (which is done
by a special HTTP header in the request). Firefox for example determines
what it needs to send by looking at the environment variable LANG. So if
your LANG is set to fi_FI.UTF-8, Firefox will request the server to
respond in Finnish. Redmine sees that and responds accordingly. It is
possible to override that in your Redmine account’s settings, or with
access to the admin panel of Redmine you can change it globally. It is
also possible to change Firefox’ language requests somewhere in the
settings.

> BR,
> xet7

Vale,
Quintus

[1]: https://www.ruby-lang.org/en/news/2015/02/23/support-for-ruby-1-9-3-has-ended/

-- 
#!/sbin/quintus
Blog: http://www.guelkerdev.de

GnuPG key: F1D8799FBCC8BC4F