A start that days with a power outage...Daily

Wednesday, April 18, 2018

Early this morning, I was attempting to connect some electrical circuits in my garden, attempting to leverage a cable that had been exposed when the old gate's pilars were demolished. That cable was very specific, 4 thick black wires with color stripes. I knew which junction box it connected to in my house, so I started planning to use it to bring electricity to the lights on the new gate.

I connected everything, then tried and "zap". After a little bit of testing, it looks like all the wires are so damaged that they connect to the ground.

Of course, this meant rebooting all my machines once more. I thank all the engineers who worked so hard on journaled filesystems Not that all journals are equal:

[  287.454297] systemd-journald[655]: File /var/log/journal/8eaac32951164615ada69ba680c64466/user-1999.journal corrupted or uncleanly shut down, renaming and replacing.

That does not help having a smooth workflow. Reconnecting to the VPN, restarting the Jenkins machine and all the VMs, etc. Takes a while every time. I don't know how I could automate all that. Some machines are just too old to auto-restart. I could probably at least configure the VMs to start automatically on boot.

{section "

SPICE common unit testingDaily

Tuesday, April 17, 2018

Recorder integration

Re-split the original patch into

  1. a part that adds the recorder,

    # a part that connects to glib logging # preparatory cleanup patches (whitespace, comments) # preparatory fix for the test suite (update after g_setenv)

However, building spice-gtk with the autoconf build system fails on macOS with:
  CC       spice-util.lo
spice-util.c:106:12: error: use of undeclared identifier 'VERSION'
    return VERSION;
           ^
1 error generated.

I've built with autoconf many times on this machine, so I'm a bit puzzled why this fails now. No obvious changes around the relevant code since 2010.

I have an old directory, spice-gtk-ac, which builds fine. Its config.h contains

/* Version number of package */
#define VERSION "0.34.31-c729-dirty"

The same thing in the local config.h, except there is an UNKNOWN version. Apparently, the git-version-gen script does not accept when spice-gtk is a submodule, it checks for a directory:

if test -n "$v"
then
    : # use $v
elif test -d .git
    && v=`git describe --abbrev=4 --match='v*' HEAD 2>/dev/null

but for a submodule, .git is a file with

gitdir: ../../.git/modules/path/to/client

That's an easy fix.

But my problem was something different. Apparently, at some point, I copied some bad config.h into the src directory, which was selected over the one in spice-gtk.

Misc

Some electricity repair at home related to the massive changes in the garden. The house was built in 1958, so they don't follow any color coding conventions. And in some cases I have no idea where the wires are running inside the house, so it's "wire hunt". Unfortunately, some of that work can only be done with electricity off and during daylight hours, which means that I have to shutdown all my machines and restart them afterwards. Time consuming twice.

Back to my keyboardDaily

Monday, April 16, 2018

The domain our house is in decided to install a new gate, and that forced us to move our own gate about 5 meters further down the road. This leads to a lot of work within the garden (new road, new gate, new electrical setup, changes in the way water arrives at the house, etc).

During the week-end, I drew new electrical cables in the garden and installed the new interphone. This required shutting down electricity a couple of time, the discovery of a few unexpected quirks in how our 1958 house is wired internally. Why is there a 4-wire electrical wire crossing my garden, what is it for? I can't measure any voltage there, but I can't rule out that it's one some breaker I did not activate...

It turns out the interphone wire in the wall was placed to low, because the contractor did not take into account the slope of the road. So on the screen, instead of the face of the visitor, you see their belly. Weird. Asked him to fix that today.

Also spent two full days outside doing a lot of heavy lifting. I'm not used to that So I feel exhausted, and welcome sitting back at my keyboard (with sore hands).

Libcommon unit test fix

Isolating the self-tests that set the environment so that the environment variable is set correctly.

Annoying issues with SPICE

There are still a few issues with today's version of SPICE that annoy me on a regular basis:

  1. Before the streaming agent starts, the mouse does not scale correctly by default. I cannot reach the screen corners. There may be a patch somewhere that addresses that, but I don't know it.
  2. It's still all too easy for lag to build up, and I still don't have the right tools to understand what's going on. That frustrates me.

Ran into a bug today where I tried to login just as the screen faded to black to activate the screen saver. The screen faded back, but there was no keyboard focus, and with the mouse issue, no obvious way to get the focus back to the login widget. Waited patiently for the screen to go black again, then I had the screen saver screen which gave focus back to the login screen correctly. Bug to file.

Misc

Filled a corporate survey... They tell you "five minutes". and this once, it was probably correct.

Friday the 13thDaily

Friday, April 13, 2018

Recorder integration in SPICE

Ran into three snags yesterday.

  1. In order to support the recorder on older variants of MinGW, I added an autoconfiguration check for sigaction. I assumed that a similar check existed for autoconf, but it does not. The closest I found is information about restartable system calls. I will need to change that check in the recorder for a check for the sigaction function, which is easier to write with autoconf.
  2. Another problem is that linking recorder exported symbols from Spice-GTK fails on Linux. I thought that I had resolved that, and the problem does not exist at the top of the branch, but apparently there is a necessary commit in the branch that I did not pull back in the integration branch.
  3. I noticed that the spice-common self-test for aborting on warnings is now failing. This is apparently due to changes I made in the way the recorder builds the linked list of recorders during initialization, which breaks the call to recorder_set_traces done in a constructor in log.c. There is an order dependency between constructors there, which is not good.

The first topic made me realize that for my Meson/Ninja comparison with make-it-quick, I had largely underestimated the cost of autoconf maintenance, by ignoring all the custom m4 macros that SPICE requires.

Regarding the order of initialization, tracing shows:

spice_log_init called
Recorder for spice_warning is 0
Recorder spice_info activated
Recorder spice_debug activated
Recorder spice_warning activated
Recorder spice_error activated
Recorder spice_critical activated
Recorder recorders activated
Recorder recorders_warning activated
Recorder recorders_error activated
Recorder signals activated
Recorder recorder_traces activated

As a result, the call to recorder_traces_set from spice_log_init has no effect. Hmmm.

This shows there is something bogus in the way constructor are managed. In theory, if library a calls libary b, then the constructors for b should run before the constructors for a, not the other way round (that is pretty much guaranteed in languages such as Ada). Not sure if that was really designed, or if it's just some "worse is better" implementation that just stayed that way...

The reason the top-of-branch works is a reordering of the recorder declarations. Integrated that. After that, the tests are less broken, but tests that depend on the function name being present fail because the recorder no longer records it. Repairing that without adding a new field to recorder entries took a little "dirty trick", which is to append the __FILE__ and __LINE__ locations to the message, and reserving the where field for the function alone. The formatting function can then skip the location information if the recorder_location tweak is not set. It's a bit strange do do extra work in that case, but it's on a slow path (rendering) anyway.

With that, all the spice-common tests pass again, with a minor change in the test suite. The issue is that the test suite uses g_setenv to set the environment, but some of the initialization testing is done in constructors. If the g_setenv is placed before forking the child, it works. But if the g_setenv is inside the child, then it fails, since the value of the environment variable in the constructor was incorrect.

Issue with the Terra Master disk array

My Terra Master disk bay regularly disconnects on a semi-regular basis. I have messages like:

[21444.774238] fuse init (API version 7.26)
[45769.678835] xhci_hcd 0000:00:14.0: Cannot set link state.
[45769.678920] usb usb4-port6: cannot disable (err = -32)
[45769.678997] usb 4-6: USB disconnect, device number 2
[45769.690860] sd 10:0:0:0: [sdb] Synchronizing SCSI cache
[45769.810762] sd 10:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[45769.890472] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 6, rd 0, flush 0, corrupt 0, gen 0
[45769.890999] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 7, rd 0, flush 0, corrupt 0, gen 0
[45769.891411] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 8, rd 0, flush 0, corrupt 0, gen 0
[45769.891808] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0
[45769.892194] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 10, rd 0, flush 0, corrupt 0, gen 0
[45769.892555] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 11, rd 0, flush 0, corrupt 0, gen 0
[45769.892845] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 12, rd 0, flush 0, corrupt 0, gen 0
[45769.893128] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 13, rd 0, flush 0, corrupt 0, gen 0
[45769.893405] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 14, rd 0, flush 0, corrupt 0, gen 0
[45769.893679] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 15, rd 0, flush 0, corrupt 0, gen 0
[45769.894006] BTRFS: error (device sdb4) in btrfs_commit_transaction:2263: errno=-5 IO failure (Error while writing out transaction)
[45769.894285] BTRFS info (device sdb4): forced readonly
[45769.894445] BTRFS warning (device sdb4): Skipping commit of aborted transaction.
[45769.894715] BTRFS: error (device sdb4) in cleanup_transaction:1876: errno=-5 IO failure
[45769.894991] BTRFS info (device sdb4): delayed_refs has NO entry
[45769.895158] BTRFS error (device sdb4): commit super ret -5
[45769.895392] BTRFS error (device sdb4): cleaner transaction attach returned -30
[45773.174877] usb 4-6: new SuperSpeed USB device number 3 using xhci_hcd
[45773.187823] usb 4-6: New USB device found, idVendor=152d, idProduct=0567
[45773.188038] usb 4-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[45773.188220] usb 4-6: Product: TerraMaster_DAS
[45773.188389] usb 4-6: Manufacturer: JMicron
[45773.188560] usb 4-6: SerialNumber: 201609040218
[45773.190965] scsi host11: uas
[45773.191811] scsi 11:0:0:0: Direct-Access     JMicron  H/W RAID5        0103 PQ: 0 ANSI: 6
[45773.223151] sd 11:0:0:0: Attached scsi generic sg2 type 0
[45773.223465] sd 11:0:0:0: [sdc] Spinning up disk...
[45774.270717] .
[45774.270809] ready
[45774.271778] sd 11:0:0:0: [sdc] 23441702912 512-byte logical blocks: (12.0 TB/10.9 TiB)
[45774.272074] sd 11:0:0:0: [sdc] 4096-byte physical blocks
[45774.272436] sd 11:0:0:0: [sdc] Write Protect is off
[45774.272618] sd 11:0:0:0: [sdc] Mode Sense: 53 00 00 08
[45774.272959] sd 11:0:0:0: [sdc] Disabling FUA
[45774.273139] sd 11:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[45774.338116]  sdc: sdc1 sdc2 sdc3 sdc4
[45774.339997] sd 11:0:0:0: [sdc] Attached SCSI disk

So apparently, while nothing happens (the above was at night, I was not active), I get this USB disconnect:

[45769.678835] xhci_hcd 0000:00:14.0: Cannot set link state.
[45769.678920] usb usb4-port6: cannot disable (err = -32)
[45769.678997] usb 4-6: USB disconnect, device number 2

immediately followed by BTRFS complaining its volume is gone:

[45769.690860] sd 10:0:0:0: [sdb] Synchronizing SCSI cache
[45769.810762] sd 10:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[45769.890472] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 6, rd 0, flush 0, corrupt 0, gen 0
[45769.890999] BTRFS error (device sdb4): bdev /dev/sdb4 errs: wr 7, rd 0, flush 0, corrupt 0, gen 0

Then about 4 seconds later, the device "reappears":

45773.174877] usb 4-6: new SuperSpeed USB device number 3 using xhci_hcd
[45773.187823] usb 4-6: New USB device found, idVendor=152d, idProduct=0567
[45773.188038] usb 4-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[45773.188220] usb 4-6: Product: TerraMaster_DAS
[45773.188389] usb 4-6: Manufacturer: JMicron
[45773.188560] usb 4-6: SerialNumber: 201609040218
[45773.190965] scsi host11: uas

but unfortunately, it does not reconnect properly, it moves to /dev/sdc instead of /dev/sdb and does not remount.

This is annoying, since this is where I hold all my "pet" VMs. I can somewhat mitigate the problem by using an UUID in /etc/fstab, but I'm clearly at risk of some data corruption.

I have three hypotheses to explain that behavior:

  1. The Terra Master is slowly failing, and this is the first sign

    # Since it's raining a lot, my power is not as stable as it should, and the Terra Master is more sensitive to power fluctuations than the PC. # The latest Fedora update I did caused it. I don't think that's the case because if I remember correclty, I saw that behavior before (I attributed it to the cat liking to jump on the warm PC. But I addressed the cat issue by making it impractical for her to get there.)

Regression in the Gitlab CI for the recorder

The Gitlab CI fails for the recorder on the struct sigaction configuration check that I had added for MinGW support.

[BEGIN]              opt linux in [top]

make[1]: *** No rule to make target '/builds/c3d/recorder/.objects/linux/opt/CFG_HAVE_struct_sigaction.h', needed by 'config.h'. Stop. make[1]: Leaving directory '/builds/c3d/recorder'

Works on my Linux machines. Weird.

Ah, apparently the installed include files were selected over the local ones. Need to check that behavior in the long run.

Switching recorder to HAVE_SIGACTION

Switching from HAVE_STRUCT_SIGACTION to HAVE_SIGACTION is easy in the recorder, but then I have the same build bug as in the GitLab CI. So there is a real issue I need to understand there.

A first problem is that I tried to simplify a rule that was looking at two different locations for the check code. That is likely to be the problem. Ooops, typo in where the configuration files are looked up by default if make-it-quick has not been installed. Easy fix.

Linker issue on Linux

Another issue is that if the installation directory does not exist, using the -rpath option for the linker fails. This is annoying. After checking with a "regular" build, the same option is sent to the linker but does not fault in that case:

gcc -shared  -fPIC -DPIC  .libs/spice-util.o .libs/spice-gtk-session.o .libs/spice-widget.o .libs/vncdisplaykeymap.o .libs/spice-grabsequence.o .libs/desktop-integration.o .libs/usb-device-widget.o .libs/spice-widget-cairo.o .libs/spice-widget-egl.o .libs/spice-widget-enums.o .libs/spice-marshal.o   -Wl,-rpath -Wl,/home/ddd/Work/spice.old/spice-gtk/src/.libs -Wl,-rpath -Wl,/usr/local/lib ./.libs/libspice-client-glib-2.0.so -lcelt051 -lgthread-2.0 -lopus -ljpeg -lz -llz4 -lpixman-1 -lssl -lcrypto -lpulse-mainloop-glib -lpulse -lgstaudio-1.0 -lgstapp-1.0 -lgstvideo-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lsasl2 -lcacard -lusb-1.0 -lusbredirhost -lusbredirparser -lphodav-2.0 -lsoup-2.4 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lepoxy -lcairo -lX11 -lm  -g -O2 -Wl,--version-script=./map-file   -pthread -Wl,-soname -Wl,libspice-client-gtk-3.0.so.5 -o .libs/libspice-client-gtk-3.0.so.5.0.0

The problem is a missing -Wl, for the -rpath argument. This repairs the Linux build and the Gitlab CI.

Warnings for type-punning

Something I had observed for a long time: GCC (but not clang, curiously) complains about type punning:

recorder.c:2009:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

The reason is that the current model does not declare the full type for a recorder in RECORDER_DECLARE. You only give the name, and you have an incomplete type. The RECORDER_INFO has to make a cast to recorder_info, which is the first field in all the recorder structs. This is a poor-man's inheritance, and would be safe in C++ (casting to base class is OK). But I'm not sure how to write that in C.

Going through an intermediate pointer when accessing the info solves the problem without breaking type safety nor signficantly changing the performance:

Without indirection (variations of ~10ns on each depending on machine's temperature):

Testing recorder version 1.02
Launching 1 normal recorder thread
Normal recorder testing in progress, please wait about 25s
Normal recorder testing completed, stopping threads
Normal test: all threads have stopped, 400314451 iterations
Recorder test analysis (Normal version):
  Iterations            = 400314451
  Iterations / ms       =    16012
  Duration per record   =       62ns
  Number of threads     =        1
Recorder test complete (Normal version), 1 threads.
  Iterations      =  400314451
  Iterations / ms =      16012
  Record cost     =         62ns
Launching 1 fast recorder thread
Fast recorder testing in progress, please wait about 25s
Fast recorder testing completed, stopping threads
Fast test: all threads have stopped, 609663579 iterations
Recorder test analysis (Fast version):
  Iterations            = 609663579
  Iterations / ms       =    24386
  Duration per record   =       41ns
  Number of threads     =        1
Recorder test complete (Fast version), 1 threads.
  Iterations      =  609663579
  Iterations / ms =      24386
  Record cost     =         41ns

With indirection:

Recorder test analysis (Normal version):
  Iterations            = 367791695
  Iterations / ms       =    14711
  Duration per record   =       67ns
  Number of threads     =        1
Recorder test complete (Normal version), 1 threads.
  Iterations      =  367791695
  Iterations / ms =      14711
  Record cost     =         67ns
Launching 1 fast recorder thread
Fast recorder testing in progress, please wait about 25s
Fast recorder testing completed, stopping threads
Fast test: all threads have stopped, 561034403 iterations
Recorder test analysis (Fast version):
  Iterations            = 561034403
  Iterations / ms       =    22441
  Duration per record   =       44ns
  Number of threads     =        1
Recorder test complete (Fast version), 1 threads.
  Iterations      =  561034403
  Iterations / ms =      22441
  Record cost     =         44ns

So really in the same ballpark.

Restart Jenkins

Restarted Jenkins, which went down after the power outage last week. Took a look, a lot of things turned red. There will be a bit of work to cleanup that mess.

Reading and learning

Interesting documentation about Fuchsia, the new OS from Google.

Meson/Ninja comparison with makeDaily

Tuesday, March 27, 2018

(Collection of stuff over a couple of days)

Does not start well for Meson:

ddd@turbo[meson] common> meson build

The Meson build system Version: 0.44.1 Source dir: /home/ddd/Work/spice-meson/libs/common Build dir: /home/ddd/Work/spice-meson/libs/common/build Build type: native build

Meson encountered an error in file meson_options.txt, line 1, column 0: Invalid kwargs for option "alignment-checks": "yield"

Removing yield from the meson_options.txt file leads to:

ddd@turbo[meson] common> meson build

The Meson build system Version: 0.44.1 Source dir: /home/ddd/Work/spice-meson/libs/common Build dir: /home/ddd/Work/spice-meson/libs/common/build Build type: native build

Meson encountered an error in file meson.build, line 4, column 0: Meson version is 0.44.1 but project requires >= 0.45.0.

A full log can be found at /home/ddd/Work/spice-meson/libs/common/build/meson-logs/meson-log.txt

The log is not that helpful:

Build started at 2018-03-27T14:58:09.633207

Main binary: /usr/bin/python3 Python system: Linux The Meson build system Version: 0.44.1 Source dir: /home/ddd/Work/spice-meson/libs/common Build dir: /home/ddd/Work/spice-meson/libs/common/build Build type: native build

But the error is actually shown in the command output above: the version is incorrect.

Udpate manually to meson 0.45.1. Then the error is:

Dependency python3 found: NO

I have python3 installed, however:

ddd@turbo[meson] common> python3 --version

Python 3.6.4

What is missing is probably python3-devel. Indeed:

ddd@turbo[meson] common> meson build

The Meson build system Version: 0.45.1 Source dir: /home/ddd/Work/spice-meson/libs/common Build dir: /home/ddd/Work/spice-meson/libs/common/build Build type: native build Project name: spice-common Native C compiler: cc (gcc 7.3.1 "cc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)") Build machine cpu family: x86_64 Build machine cpu: x86_64 Has header "alloca.h": YES Has header "arpa/inet.h": YES Has header "dlfcn.h": YES Has header "inttypes.h": YES Has header "malloc.h": YES Has header "memory.h": YES Has header "netinet/in.h": YES Has header "stddef.h": YES Has header "stdint.h": YES Has header "stdlib.h": YES Has header "strings.h": YES Has header "string.h": YES Has header "sys/socket.h": YES Has header "sys/stat.h": YES Has header "sys/types.h": YES Has header "unistd.h": YES Has header "vfork.h": NO Checking for function "alloca": YES Checking for function "dup2": YES Checking for function "floor": YES Checking for function "fork": YES Checking for function "inet_ntoa": YES Checking for function "memmove": YES Checking for function "memset": YES Checking for function "pow": YES Checking for function "sqrt": YES Checking for function "vfork": YES Found pkg-config: /usr/bin/pkg-config (1.3.12) Native dependency spice-protocol found: YES 0.12.14 Native dependency glib-2.0 found: YES 2.54.3 Native dependency gio-2.0 found: YES 2.54.3 Native dependency gthread-2.0 found: YES 2.54.3 Native dependency pixman-1 found: YES 0.34.0 Native dependency openssl found: YES 1.1.0g Native dependency opus found: YES 1.2.1 Native dependency celt051 found: YES 0.5.1.3 Native dependency python3 found: YES 3.6 Native dependency libcacard found: YES 2.5.3 meson.build:157: WARNING: This project is only intended to be used as a subproject! Program asciidoc found: YES (/usr/bin/asciidoc) Configuring config.h using configuration Build targets in project: 17 Found ninja-1.8.2 at /usr/bin/ninja

Timing comparisons

Building the SPICE server on Turbo, 5 builds to get an idea of the variation.

Tools Clean reds.c log.h Description size Description language Build commands
Today's autotools 56.0-57.3s 2.98-3.28s 22.6-23.2s 13 files, 1149 lines, 31.7K autoconf (m4+shell) + automake (make-like) autoreconf -vfi && ./configure && make -j24
Meson/Ninja 7.65-7.85s 2.98-3.19s 5.51-5.60s 8 files, 553 lines, 16.4K meson (custom syntax, Python-like) meson build && ninja -C build
Pure make (debug) 4.29-4.55s 0.62-0.94s 1.48-1.68s 7 files, 372 lines, 10.0K Pure make make -j24
Pure make (opt) 19.21-19.42s 1.19-1.44s 2.96-3.05s 7 files, 372 lines, 10.0K Pure make make -j24

Resuming this blogDaily

Monday, March 26, 2018

After

UnmailingDaily

Wednesday, January 31, 2018

Mail backup.

Code reviews.

Some thinking and mail exchanges on spectre / meltdown, notably with respect to migration and VM usage.

Installing Redmine

I started with these instructions, but they seem quite outdated. Summary of what I know needs to be done to install:

Let's start with the dependencies:

yum -y install zlib-devel curl-devel openssl-devel httpd-devel apr-devel apr-util-devel mysql-devel

Then since I'd like to use postgresql and not MySQL or MariaDB, let's try that first:

yum install postgresql postgresql-server

Open the firewall for Apache (port 80), otherwise access is denied by default:

% firewall-config

or better yet

% firewall-cmd --zone=public --add-port=3000/tcp --permanent

Ruby is installed, and I initially thought that the built-in v2.0 was OK:

% ruby -v
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]

This gives me a correct version of GEM:

% gem -v
2.0.14.1

But it turns out that Passenger install fails:

% gem install passenger
Fetching: rake-12.3.0.gem (100%)
Successfully installed rake-12.3.0
Fetching: rack-2.0.3.gem (100%)
ERROR:  Error installing passenger:
	rack requires Ruby version >= 2.2.2.

So it turns out the correct solution is to manually upgrade Ruby to the latest stable:

% wget https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.0.tar.gz
% tar xvfz ruby-2.5.0.tar.gz
% cd ruby-2.5.0/
% ./configure
% make

Then you get:

% ruby -v
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]

And then installing Passenger works:

% gem install passenger
gem install passenger
Fetching: rack-2.0.3.gem (100%)
Successfully installed rack-2.0.3
Fetching: passenger-5.2.0.gem (100%)
Building native extensions. This could take a while...
Successfully installed passenger-5.2.0
Parsing documentation for rack-2.0.3
Installing ri documentation for rack-2.0.3
Parsing documentation for passenger-5.2.0
Installing ri documentation for passenger-5.2.0
Done installing documentation for rack, passenger after 53 seconds
2 gems installed

Then the rest of the installation works semi-OK:

% cd /var/www
% svn co http://svn.redmine.org/redmine/branches/3.4-stable redmine
% systemctl restart httpd

Installing PostgreSQL

Check that postgresql is running OK:

% psql
psql: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

So need to install and setup:

% sudo yum install postgresql-server
% posgresql-setup initdb
Initializing database ... OK
% systemctl start postgresql
% systemctl enable postgresql

For postgres, the super-user is user postgres:

% su - postgres
% psql
postgres=# alter role postgres with encrypted password 'stuff';
postgres=# create user redmine with encrypted password 'stuff2';

Creating the database with UTF-8 encoding fails:

postgres=# create database redmine with encoding 'UTF-8';
ERROR:  new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)
HINT:  Use the same encoding as in the template database, or use template0 as template.

So you need:

postgres=# create database redmine with template = template0 encoding 'UTF-8';

I also found an alternative that, if I understand correctly, recreates template1 to default to allowing this kind of creation:

postgres=# update pg_database set datallowconn = TRUE where datname = 'template0';
UPDATE 1
postgres=# c template0
You are now connected to database "template0" as user "postgres".
template0=# update pg_database set datistemplate = FALSE where datname = 'template1';
UPDATE 1
template0=# drop database template1;
DROP DATABASE
template0=# create database template1 with template = template0 encoding = 'UTF8';
CREATE DATABASE
template0=# update pg_database set datistemplate = TRUE where datname = 'template1';
UPDATE 1
template0=# c template1
You are now connected to database "template1" as user "postgres".
template1=# update pg_database set datallowconn = FALSE where datname = 'template0';
UPDATE 1
template1=# create database redmine with encoding 'UTF-8';
CREATE DATABASE

After that, the original redmine database creation works.

It's probably a good idea to create the database so that owner is redmine, see below.

MariaDB alternative

The alternative for MySQL is:

% mysql -u root -p
Enter password:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

Installing MariaDB solves it:

yum insall mariadb mariadb-devel

systemctl start mariadb systemctl enable mariadb

Then you can create the database:

% mysql -u root -p
MariaDB [(none)]> set password for 'root'@'localhost' = password('my password');
MariaDB [(none)]> create database redmine character set utf8;
MariaDB [(none)]> create user 'redmine'@'localhost' identified by 'somepass';
MariaDB [(none)]> grant all privileges on redmine.* to 'redmine'@'localhost';

Redmine configuration

Edit the configuration file from the sample:

% cd /var/www/redmine/config/
% cp database.yml.example database.yml

and edit to select the postgresql adapter:

production:
  adapter: postgresql
  database: redmine
  host: localhost
  username: redmine
  password: somepassword

Add the gem bundler:

% gem install bundler
Fetching: bundler-1.16.1.gem (100%)
Successfully installed bundler-1.16.1
Parsing documentation for bundler-1.16.1
Installing ri documentation for bundler-1.16.1
Done installing documentation for bundler after 5 seconds
1 gem installed

The documentation recommends to update the Gemfile, but that does not appear necessary on a modern version of Redmine. So on to installing the dependencies:

% cd /var/www/redmine
% bundle install

Note that if postgresql-devel is not installed, you get:

Installing pg 0.18.4 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory: /usr/local/lib/ruby/gems/2.5.0/gems/pg-0.18.4/ext

/usr/local/bin/ruby -r ./siteconf20180131-22563-n36glk.rb extconf.rb checking for pg_config... yes Using config values from /usr/bin/pg_config checking for libpq-fe.h... no Can't find the 'libpq-fe.h header *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options.

Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/usr/local/bin/$(RUBY_BASE_NAME) --with-pg --without-pg --enable-windows-cross --disable-windows-cross --with-pg-config --without-pg-config --with-pg_config --without-pg_config --with-pg-dir --without-pg-dir --with-pg-include --without-pg-include=${pg-dir}/include --with-pg-lib --without-pg-lib=${pg-dir}/lib

To see why this extension failed to compile, please check the mkmf.log which can be found here:

/usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/pg-0.18.4/mkmf.log

extconf failed, exit code 1 Gem files will remain installed in /usr/local/lib/ruby/gems/2.5.0/gems/pg-0.18.4 for inspection. Results logged to /usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/pg-0.18.4/gem_make.out

An error occurred while installing pg (0.18.4), and Bundler cannot continue. Make sure that `gem install pg -v '0.18.4'` succeeds before bundling.

In Gemfile: pg

Interestingly, I learned about a nice feature of yum that I did not know about, which is that you can install based on a file, without knowing which package this is :

% yum install /usr/include/libpq-fe.h

So the alternative is to

% yum install postgresql-devel

After that, % bundle install should give you the following message:

Bundle complete! 32 Gemfile dependencies, 73 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Post-install message from yard:
--------------------------------------------------------------------------------
As of YARD v0.9.2:

RubyGems "--document=yri,yard" hooks are now supported. You can auto-configure YARD to automatically build the yri index for installed gems by typing:

$ yard config --gem-install-yri

See `yard config --help` for more information on RubyGems install hooks.

You can also add the following to your .gemspec to have YARD document your gem on install:

spec.metadata["yard.run"] = "yri" # use "yard" to build full HTML docs.

--------------------------------------------------------------------------------

Following up on the suggestion about yard:

% yard config --gem-install-yri
Updated ~/.gemrc: 'gem: --document=yri'

Then update /var/www/redmine/config/environment.rb with

ENV['RAILS_ENV'] ||= 'production'

Is that really needed?

The documentation then suggests using the deprecated command:

% RAILS_ENV=production bundle exec rake generate_session_store
Note: The rake task generate_session_store has been deprecated, please use the replacement version generate_secret_token

So let's do the "right" thing:

% RAILS_ENV=production bundle exec rake generate_secret_token

and then migrating the database:

% RAILS_ENV=production bundle exec rake db:migrate

This does not work without fixing permissions:

rake aborted!
PG::ConnectionBad: FATAL:  Ident authentication failed for user "postgres"
/var/www/redmine/app/models/custom_field.rb:38:in `'
/var/www/redmine/app/models/custom_field.rb:18:in `'
/var/www/redmine/lib/redmine/field_format.rb:108:in `field_attributes'
/var/www/redmine/lib/redmine/field_format.rb:111:in `'
/var/www/redmine/lib/redmine/field_format.rb:57:in `'
/var/www/redmine/lib/redmine/field_format.rb:21:in `'
/var/www/redmine/lib/redmine/field_format.rb:20:in `'
/var/www/redmine/lib/redmine.rb:40:in `'
/var/www/redmine/config/initializers/30-redmine.rb:6:in `'
/var/www/redmine/config/environment.rb:16:in `'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `
' Tasks: TOP => db:migrate => environment

I also tried as postgres user, but that does not work any better:

% su - postgres
Last login: Wed Jan 31 10:35:47 EST 2018 on pts/2
-bash-4.2$ cd /var/www/redmine/
-bash-4.2$ RAILS_ENV=production bundle exec rake db:migrate
Rails Error: Unable to access log file. Please ensure that /var/www/redmine/log/production.log exists and is writable (ie, make it writable for user and group: chmod 0664 /var/www/redmine/log/production.log). The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
rake aborted!
PG::ConnectionBad: FATAL:  Ident authentication failed for user "postgres"
/var/www/redmine/app/models/custom_field.rb:38:in `'
/var/www/redmine/app/models/custom_field.rb:18:in `'
/var/www/redmine/lib/redmine/field_format.rb:108:in `field_attributes'
/var/www/redmine/lib/redmine/field_format.rb:111:in `'
/var/www/redmine/lib/redmine/field_format.rb:57:in `'
/var/www/redmine/lib/redmine/field_format.rb:21:in `'
/var/www/redmine/lib/redmine/field_format.rb:20:in `'
/var/www/redmine/lib/redmine.rb:40:in `'
/var/www/redmine/config/initializers/30-redmine.rb:6:in `'
/var/www/redmine/config/environment.rb:16:in `'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `
' Tasks: TOP => db:migrate => environment (See full trace by running task with --trace)

Configuring a redmine user

Adding the user:

% useradd redmine
% chown -R redmine /var/www/redmine

That's not enough, still failure connecting to database.

You also need to make sure that user 'redmine' is the owner of the database:

postgres=# create database redmine with encoding 'UTF-8' owner redmine;
CREATE DATABASE
postgres=# alter user redmine superuser createrole createdb replication;
ALTER ROLE

I just love how the syntax is so order-dependent:

postgres=# create database redmine owner redmine;
CREATE DATABASE
create database redmine owner redmine with encoding 'UTF-8';
ERROR:  syntax error at or near "with encoding"
LINE 1: create database redmine owner redmine with encoding 'UTF-8';

There are suggestions on how to edit /var/lib/pgsql/data/pg_hba.conf, and modifying the localhost entry. That still does not work on RHEL 7.4. The /var/lib/pgsql/data/pg_log/postgresql-Wed.log shows

LOG:  could not connect to Ident server at address "::1", port 113: Connection refused

Turns out that the problem is that RHEL7.4 defaults localhost to IPv6, so need to add trust for the IPv6 localhost in /var/lib/pgsql/data/pg_hba.conf.

Now the following works:

% RAILS_ENV=production bundle exec rake db:migrate
== 1 Setup: migrating =========================================================
-- create_table("attachments", {:force=>true})
   -> 0.0586s
-- create_table("auth_sources", {:force=>true})
   -> 0.0333s
-- create_table("custom_fields", {:force=>true})
   -> 0.0666s
-- create_table("custom_fields_projects", {:id=>false, :force=>true})
   -> 0.0018s
-- create_table("custom_fields_trackers", {:id=>false, :force=>true})
   -> 0.0014s
-- create_table("custom_values", {:force=>true})
   -> 0.0966s
-- create_table("documents", {:force=>true})
   -> 0.0332s
-- add_index("documents", ["project_id"], {:name=>"documents_project_id"})
...

== 20170309214320 AddProjectDefaultAssignedToId: migrating ==================== -- add_column(:projects, :default_assigned_to_id, :integer, {:default=>nil}) -> 0.0008s -- column_exists?(:projects, :default_assignee_id, :integer) -> 0.0014s == 20170309214320 AddProjectDefaultAssignedToId: migrated (0.0024s) ===========

== 20170320051650 ChangeRepositoriesExtraInfoLimit: migrating ================= == 20170320051650 ChangeRepositoriesExtraInfoLimit: migrated (0.0000s) ========

== 20170418090031 AddViewNewsToAllExistingRoles: migrating ==================== == 20170418090031 AddViewNewsToAllExistingRoles: migrated (0.0080s) ===========

== 20170419144536 AddViewMessagesToAllExistingRoles: migrating ================ == 20170419144536 AddViewMessagesToAllExistingRoles: migrated (0.0069s) =======

Then the (probably optional) default data:

% RAILS_ENV=production bundle exec rake redmine:load_default_data

Select language: ar, az, bg, bs, ca, cs, da, de, el, en, en-GB, es, es-PA, et, eu, fa, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, lv, mk, mn, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sq, sr, sr-YU, sv, th, tr, uk, vi, zh, zh-TW [en] en ==================================== Default configuration data loaded.

Need to create the entry point for Redmine, copied /var/www/redmine/public/dispatch.fcgi.example as /var/www/redmine/public/dispatch.fcgi and then changed the ruby environment line to point to the one I had compiled:

#!/usr/local/bin/ruby

Make it executable:

chmod 755 public/dispatch.cgi

Create an Apache configuration file /etc/httpd/conf.d/redmine.conf with stuff lifted in part from the .htaccess provided with Redmine (remove the MaxRequestLen option :


    ServerName myservername
    ServerAdmin myadmin@mycompany.com
    DocumentRoot /var/www/redmine/public/
    ErrorLog logs/redmine_error_log

#If you are using mod_fcgid and are going to upload files larger than #131072 bytes you should consider adding the following line #that allows to upload files up to 20 mb Options Indexes ExecCGI FollowSymLinks Order allow,deny Allow from all AllowOverride all AddHandler fastcgi-script .fcgi AddHandler fcgid-script .fcgi Options +FollowSymLinks +ExecCGI RewriteEngine On RewriteRule ^$ index.html [QSA] RewriteRule ^([^.]+)$ $1.html [QSA] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ dispatch.fcgi [QSA,L] RewriteRule ^(.*)$ dispatch.fcgi [QSA,L] ErrorDocument 500 "/500.html" ErrorDocument 404 "/404.html"

I still get the main RHEL page, and if I fetch the FCGI itself, I get the source code for the script, it does not get executed.

CGI script enablement

Checking if Apache has the fastcgi module:

% apachectl -M

No answer, option not listed in the man page. So

% apachectl fullstatus
The 'links' package is required for this functionality.

Installing links, then total lack of success

% apachectl fullstatus
                                 Page not found

The page you were trying to access doesn't exist or has been removed. [1]Back

References

Visible links 1. javascript:history.back()

OK. Approach number #2:

% httpd -M
Loaded Modules:
 core_module (static)
 so_module (static)
 http_module (static)
 access_compat_module (shared)
 ...

Is there a fast CGI module? Nope:

% httpd -M | grep cgi
 proxy_fcgi_module (shared)
 proxy_scgi_module (shared)
 cgi_module (shared)

According to instructions, need to add some dependencies for building:

% yum install libtool httpd-devel apr-devel apr

Then the build itself:

cd /usr/local/src/
wget http://www.fastcgi.com/dist/mod_fastcgi-current.tar.gz

tar -zxvf mod_fastcgi-current.tar.gz cd mod_fastcgi-2.4.6/ cp Makefile.AP2 Makefile make top_dir=/usr/lib/httpd make install top_dir=/usr/lib/httpd

Strike that. Better solution is:

% yum install mod_fcgid

Getting 400 errors (Bad Request). In the redmine_error_log, I see:

[Thu Feb 01 08:40:22.868890 2018] [authz_core:error] [pid 13062] [client 192.168.77.22:58420] AH01630: client denied by server configuration: /var/www/redmine/public/.html

Had to go to trace level 3 in Apache to find something:

auth phase 'translate' gave status 400: /dispatch.fcgi

What does that mean now? I find it amazing that something could end up in a "Bad Request" with nary a bleep in the Apache error log...

Ran the dispatch.fcgi locally:

% ./dispatch.fcgi
/usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require': cannot load such file -- fcgi (LoadError)
	from /usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `block in require'
	from /usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
	from /usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
	from /usr/local/lib/ruby/gems/2.5.0/gems/rack-1.6.8/lib/rack/handler/fastcgi.rb:1:in `'
	from /usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
	from /usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `block in require'
	from /usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:240:in `load_dependency'
	from /usr/local/lib/ruby/gems/2.5.0/gems/activesupport-4.2.8/lib/active_support/dependencies.rb:274:in `require'
	from ./dispatch.fcgi:20:in `
'

OK, finally found an interesting idea based on that message. It looks like I need to add {tt ""fcgi""} to the Gemfile and re-run bundle install. But that fails:

Fetching fcgi 0.9.2.1
Installing fcgi 0.9.2.1 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory: /usr/local/lib/ruby/gems/2.5.0/gems/fcgi-0.9.2.1/ext/fcgi

/usr/local/bin/ruby -r ./siteconf20180201-16089-15rs6mj.rb extconf.rb checking for fcgiapp.h... no checking for fastcgi/fcgiapp.h... no

current directory: /usr/local/lib/ruby/gems/2.5.0/gems/fcgi-0.9.2.1/ext/fcgi make "DESTDIR=" clean make: *** No rule to make target `clean'. Stop.

current directory: /usr/local/lib/ruby/gems/2.5.0/gems/fcgi-0.9.2.1/ext/fcgi make "DESTDIR=" make: *** No targets. Stop.

make failed, exit code 2

Gem files will remain installed in /usr/local/lib/ruby/gems/2.5.0/gems/fcgi-0.9.2.1 for inspection. Results logged to /usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/fcgi-0.9.2.1/gem_make.out

An error occurred while installing fcgi (0.9.2.1), and Bundler cannot continue. Make sure that `gem install fcgi -v '0.9.2.1'` succeeds before bundling.

In Gemfile: fcgi

Annoying. Another install:

% yum install fcgi-devel
No package fcgi-devel available.
Error: Nothing to do

OK. Trying to use the EPEL version then:

% cd /tmp
% wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
% rpm -ivh epel-release-latest-7.noarch.rpm

Then getting the fcgi-devel package succeeds:

% yum install fcgi-devel

Then backtracking a bit.

% bundle install

Now at least running ./dispatch.fcgi manually works. But the Bad Request is still there.

If I remove the following rewrite rules, then instead of a Bad Request, I get an Internal error

    RewriteRule ^$ index.html [QSA]
    RewriteRule ^([^.]+)$ $1.html [QSA]
    RewriteCond %{REQUEST_FILENAME} !-f
    
	RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
    
    
	RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
    

Does that mean the rewrite module has a bug?

OK. It turns out it's the .htaccess sample that has some error, there is a missing leading / in /dispatch.fcgi. After that, what I get is:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at rhspice-team@redhat.com to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

If I write to a file from within the dispatch.fcgi file, it's clearly only called if I run it manually, not from the httpd server. Something is blocking it. Nothing in the error_log from Apache or Redmine, beyond:

[Thu Feb 01 12:20:32.575195 2018] [fcgid:info] [pid 19905] mod_fcgid: server rhel74-muse:/var/www/redmine/public/dispatch.fcgi(20265) started
[Thu Feb 01 12:20:32.576718 2018] [fcgid:info] [pid 19905] mod_fcgid: server rhel74-muse:/var/www/redmine/public/dispatch.fcgi(20266) started
[Thu Feb 01 12:20:38.582928 2018] [fcgid:info] [pid 19905] mod_fcgid: process /var/www/redmine/public/dispatch.fcgi(20266) exit(communication error), terminated by calling exit(), return code: 255
[Thu Feb 01 12:20:38.582987 2018] [fcgid:info] [pid 19905] mod_fcgid: process /var/www/redmine/public/dispatch.fcgi(20265) exit(communication error), terminated by calling exit(), return code: 255

When I run it manually, I get return code 0.

Maybe SELinux is getting in the way again.

% sestatus -b | grep httpd | grep cgi
httpd_enable_cgi                            on

So that seems to be allowed.

Looked at the docker image that is running Redmine to see what process is running. Apparently, the web server is NOT Apache:

% docker exec -it 9 bash
root@96ac71a4560b:/usr/src/redmine# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
redmine      1     0  0  2017 ?        00:02:45 /usr/local/bin/ruby bin/rails server -b 0.0.0.0
root      1546     0  0 17:39 ?        00:00:00 bash
root      1573  1546  0 17:45 ?        00:00:00 ps -ef

So apparently I also need to manually run the Rails server.

% /usr/local/bin/ruby bin/rails server -b 0.0.0.0 -e production
=> Booting WEBrick
=> Rails 4.2.8 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2018-02-01 12:46:34] INFO  WEBrick 1.4.2
[2018-02-01 12:46:34] INFO  ruby 2.5.0 (2017-12-25) [x86_64-linux]
...
/usr/local/lib/ruby/2.5.0/socket.rb:201:in `bind': Address already in use - bind(2) for 0.0.0.0:3000 (Errno::EADDRINUSE)

Removing the following from redmine.conf:

Listen *:3000

Then the server starts correctly:

 /usr/local/bin/ruby bin/rails server -b 0.0.0.0 -e production
=> Booting WEBrick
=> Rails 4.2.8 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2018-02-01 12:49:02] INFO  WEBrick 1.4.2
[2018-02-01 12:49:02] INFO  ruby 2.5.0 (2017-12-25) [x86_64-linux]
[2018-02-01 12:49:02] INFO  WEBrick::HTTPServer#start: pid=21470 port=3000

So maybe now the dispatcher works? Nope. But connecting to https://rhel74-muse:3000 now works! So I guess all that crap was for nothing.

Dumping the redmine database:

% pg_dump --host=localhost --username=redmine --dbname=redmine --file=redmine-db.sql

Restoring it:

% psql --file=/tmp/redmine/redmine-db.sql --host=localhost --username=redmine --dbname=redmine

Problem is that this runs into a number of issues:

SET
psql:/tmp/redmine/redmine-db.sql:9: ERROR:  unrecognized configuration parameter "lock_timeout"
psql:/tmp/redmine/redmine-db.sql:10: ERROR:  unrecognized configuration parameter "idle_in_transaction_session_timeout"
SET
SET
SET
SET
psql:/tmp/redmine/redmine-db.sql:15: ERROR:  unrecognized configuration parameter "row_security"
CREATE EXTENSION
COMMENT
SET
SET
SET
CREATE TABLE
ALTER TABLE
psql:/tmp/redmine/redmine-db.sql:70: ERROR:  syntax error at or near "AS"
LINE 2:     AS integer
            ^
psql:/tmp/redmine/redmine-db.sql:73: ERROR:  relation "attachments_id_seq" does not exist
psql:/tmp/redmine/redmine-db.sql:79: ERROR:  relation "attachments_id_seq" does not exist
CREATE TABLE
ALTER TABLE
psql:/tmp/redmine/redmine-db.sql:118: ERROR:  syntax error at or near "AS"
LINE 2:     AS integer
            ^
psql:/tmp/redmine/redmine-db.sql:121: ERROR:  relation "auth_sources_id_seq" does not exist
psql:/tmp/redmine/redmine-db.sql:127: ERROR:  relation "auth_sources_id_seq" does not exist
CREATE TABLE
ALTER TABLE
psql:/tmp/redmine/redmine-db.sql:159: ERROR:  syntax error at or near "AS"
LINE 2:     AS integer

Issues with the versions of Postgres, my docker image has:

% psql --version
psql (PostgreSQL) 10.0

The RHEL 7.4 VM has:

%  psql --version
psql (PostgreSQL) 9.2.23

So that means upgrading the database too. Apparently not very hard:

% yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-redhat10-10-1.noarch.rpm
% yum install postgresql10-server postgresql10

Then play it again, Sam!

Copying files from /usr/src/redmine/files.

The docker route

Self-explanatory:

% docker
bash: docker: command not found...
% curl -sSL https://get.docker.com/ | sh
  1. Executing docker install script, commit: 1d31602

WARNING: rhel is now only supported by Docker EE Check https://store.docker.com for information on Docker EE

So basically you have to pay for docker, I guess.