You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Sam Ruby <ru...@intertwingly.net> on 2019/10/19 04:05:18 UTC
Mac OSX read only file system
With the latest update (Catalina):
$ sudo mkdir /srv
mkdir: /srv: Read-only file system
Previously, whimsy tools were set up to determine file names based on
a ~/.whimsy config file. Over time, much of this has changed to
presume /srv. Most problematic:
$LOAD_PATH.unshift '/srv/whimsy/lib'
Not sure what the solution would be.
- Sam Ruby
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by Roy Lenferink <rl...@apache.org>.
Thanks for the reply Sam!
I think I learned another thing today, don't just trust 'docker run
hello-world' to verify your docker configuration ;) In the end it was a
network problem with Docker on my side and strange enough a reboot solved
it.
The image is still building but I'll keep this list updated.
Op di 19 nov. 2019 om 22:15 schreef Sam Ruby <ru...@intertwingly.net>:
> On Tue, Nov 19, 2019 at 2:13 PM Roy Lenferink <rl...@apache.org>
> wrote:
> >
> > I just tried the Docker instructions, however the rake docker:update
> > command is failing for me with the error shown below. Am I maybe missing
> > something?
>
> [snip]
>
> > Err:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
> > Temporary failure resolving 'security.ubuntu.com'
>
> It looks like you might be missing a working network connection?
>
> Does ping security.ubuntu.com work for you?
>
> - Sam Ruby
>
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Nov 19, 2019 at 2:13 PM Roy Lenferink <rl...@apache.org> wrote:
>
> I just tried the Docker instructions, however the rake docker:update
> command is failing for me with the error shown below. Am I maybe missing
> something?
[snip]
> Err:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
> Temporary failure resolving 'security.ubuntu.com'
It looks like you might be missing a working network connection?
Does ping security.ubuntu.com work for you?
- Sam Ruby
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by Roy Lenferink <rl...@apache.org>.
I just tried the Docker instructions, however the rake docker:update
command is failing for me with the error shown below. Am I maybe missing
something?
I am on CentOS 8.0.1905 with Docker version 19.03.5, build 633a0ea.
I also tested using podman with podman-compose (with alias docker='podman'
etc..), however this doesn't even start with the rake docker:update command.
Regards,
Roy
[root@centos8 whimsy]# rake docker:update
docker-compose build web
Building web
Step 1/8 : FROM ubuntu:18.04
18.04: Pulling from library/ubuntu
7ddbc47eeb70: Pull complete
c1bbdc448b72: Pull complete
8c3b70e39044: Pull complete
45d437916d57: Pull complete
Digest:
sha256:6e9f67fa63b0323e9a1e587fd71c561ba48a034504fb804fd26fd8800039835d
Status: Downloaded newer image for ubuntu:18.04
---> 775349758637
Step 2/8 : ENV GEM_HOME="/srv/gems" LANG=C.UTF-8 LC_ALL=C.UTF-8
---> Running in 185fda5837b4
Removing intermediate container 185fda5837b4
---> 65ccad352b15
Step 3/8 : RUN apt-get update && apt-get install -y curl
software-properties-common apt-utils && curl -sL
https://deb.nodesource.com/setup_12.x | bash - && echo "deb
http://opensource.wandisco.com/ubuntu bionic svn110" >
/etc/apt/sources.list.d/subversion.list && curl -sL
http://opensource.wandisco.com/wandisco-debian-new.gpg | apt-key add
- && apt-get update && DEBIAN_FRONTEND='noninteractive' apt-get
install -y apache2 subversion git build-essential
libgmp3-dev libldap2-dev libsasl2-dev python3-pip
ruby-dev zlib1g-dev imagemagick img2pdf nodejs
procmail poppler-utils texlive-extra-utils gnupg2
libcurl4-openssl-dev libssl-dev apache2-dev libapr1-dev
libaprutil1-dev && gem install bundler passenger
--install_dir=/var/lib/gems/2.5.0 && passenger-install-apache2-module
--auto && passenger-install-apache2-module --snippet >
/etc/apache2/conf-enabled/passenger.conf && pip3 install img2pdf &&
a2enmod cgi && a2enmod headers && a2enmod rewrite && a2enmod
authnz_ldap && a2enmod speling && a2enmod remoteip && a2enmod
expires && a2enmod proxy_wstunnel && echo "ServerName whimsy.local"
> /etc/apache2/conf-enabled/servername.conf
---> Running in ef2b4a44e5db
Err:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Temporary failure resolving 'security.ubuntu.com'
Err:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Temporary failure resolving 'archive.ubuntu.com'
Err:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Temporary failure resolving 'archive.ubuntu.com'
Err:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Temporary failure resolving 'archive.ubuntu.com'
Reading package lists...
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/bionic/InRelease
Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch
http://archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease Temporary
failure resolving 'archive.ubuntu.com'
W: Failed to fetch
http://archive.ubuntu.com/ubuntu/dists/bionic-backports/InRelease
Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch
http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease
Temporary failure resolving 'security.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old ones
used instead.
Reading package lists...
Building dependency tree...
Reading state information...
Package apt-utils is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
apt
E: Unable to locate package curl
E: Unable to locate package software-properties-common
E: Package 'apt-utils' has no installation candidate
ERROR: Service 'web' failed to build: The command '/bin/sh -c apt-get
update && apt-get install -y curl software-properties-common apt-utils
&& curl -sL https://deb.nodesource.com/setup_12.x | bash - && echo
"deb http://opensource.wandisco.com/ubuntu bionic svn110" >
/etc/apt/sources.list.d/subversion.list && curl -sL
http://opensource.wandisco.com/wandisco-debian-new.gpg | apt-key add
- && apt-get update && DEBIAN_FRONTEND='noninteractive' apt-get
install -y apache2 subversion git build-essential
libgmp3-dev libldap2-dev libsasl2-dev python3-pip
ruby-dev zlib1g-dev imagemagick img2pdf nodejs
procmail poppler-utils texlive-extra-utils gnupg2
libcurl4-openssl-dev libssl-dev apache2-dev libapr1-dev
libaprutil1-dev && gem install bundler passenger
--install_dir=/var/lib/gems/2.5.0 && passenger-install-apache2-module
--auto && passenger-install-apache2-module --snippet >
/etc/apache2/conf-enabled/passenger.conf && pip3 install img2pdf &&
a2enmod cgi && a2enmod headers && a2enmod rewrite && a2enmod
authnz_ldap && a2enmod speling && a2enmod remoteip && a2enmod
expires && a2enmod proxy_wstunnel && echo "ServerName whimsy.local"
> /etc/apache2/conf-enabled/servername.conf' returned a non-zero code: 100
rake aborted!
Command failed with status (1): [docker-compose build web...]
/root/whimsy/whimsy/Rakefile:262:in `block (3 levels) in <top (required)>'
/root/whimsy/whimsy/Rakefile:261:in `chdir'
/root/whimsy/whimsy/Rakefile:261:in `block (2 levels) in <top (required)>'
/usr/share/gems/gems/rake-12.3.0/exe/rake:27:in `<top (required)>'
Tasks: TOP => docker:update => docker:build
(See full trace by running task with --trace)
[root@centos8 whimsy]#
Op di 19 nov. 2019 om 18:49 schreef Sam Ruby <ru...@intertwingly.net>:
> On Tue, Nov 19, 2019 at 9:15 AM sebb <se...@gmail.com> wrote:
> >
> > On Tue, 19 Nov 2019 at 13:34, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > > On Tue, Nov 19, 2019 at 8:17 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > On Tue, 19 Nov 2019 at 12:26, sebb <se...@gmail.com> wrote:
> > > >
> > > > > docker:update had issues pulling down various svn repos, e.g.
> > > > >
> > > > > svn: E170013: Unable to connect to a repository at URL ...
> > > > > svn: E125009: Invalid config: unable to load certificate file
> > > > > '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
> > > > >
> > > > > I was able to remove the Invalid config error by changing
> /Users/sebb
> > > =>
> > > > > /root
> > > > > However I then got the error:
> > > > >
> > > > > svn: E000111: Error running context: Connection refused
> > > > >
> > > > > I assume that is because my SVN is set to grab passwords from the
> macOS
> > > > > keychain
> > > > >
> > > > >
> > > > Turns out that SVN was down at the time.
> > > >
> > > > Once I copied the cert to the expected place it worked OK.
> > > >
> > > > I've just realised that the /srv/svn directory is mounted from the
> host
> > > OS.
> > > > So checkouts in the image actually update the host working directory.
> > > > Given that, it seems to me it would make more sense to do the
> check-out
> > > on
> > > > the host under /srv, and mount that instead.
> > >
> > > Two issues:
> > >
> > > 1) From time to time subversion makes changes to the file format. It
> > > could be the case that the version of subversion you have on the host
> > > is not compatible with the version of subversion in the container.
> > >
> >
> > In which case having the checkout on the host filing system is risky.
> > It would be safer to have the data all within the container, and not
> > accessible from the host.
> > AFAICT it should not take any more space overall.
>
> It's complicated, and a lot depends on what the use cases we intend to
> support are.
>
> For now, I've updated the Dockerfile to install a compatible version
> of subversion, and updated DOCKER.md to explain the constraints.
>
> I actually developed these files using the /srv directory from the
> MACOSX instructions.
>
> My thoughts are that most people would feel more comfortable doing
> their browsing and updates in the host environment, so a shared mount
> would be in order.
>
> I definitely would not want to put repository data in images as those
> are frozen (i.e., updates would be done in separate layers and would
> take up more space). Similarly, I would not want to put repository
> data in container space as those go away when the container exits.
> Putting this data into a docker volume would work (and may be faster),
> but may be less convenient for people that want to access the data
> from their host.
>
> These constraints are particularly true for the whimsy directory. I'm
> comfortable exec'ing into the container and editing the files using
> vim, but others may want to use their Mac IDEs.
>
> > But for those who can cope with the possible issue, there could be
> another
> > build that uses host data under /svn
>
> I do most of my whimsy work on my Ubuntu desktop machine, but I
> recently updated the MACOSX instructions and have this working on my
> laptop. I'm more likely to use those instructions than the container
> instructions, but being able to share a /srv directory would be
> convenient for me, allowing me to switch between the two.
>
> > 2) Doing the checkout on the host only defers the problem. A number
> > > of whimsy processes access svn (checkouts and commits).
> > >
> > >
> > It might be useful to be able to disable commits for testing purposes.
> > This is also true of LDAP.
>
> Agreed, though for testing purposes I have defined a locally hosted
> subversion repository for the board agenda tests, allowing commits to
> be tested.
>
> > Regarding the SVN checkouts, maybe it would make sense to start by
> checking
> > out only the top-level files/directories for some of the less-used/larger
> > trees.
>
> The largest are iclas, cclas, grants, and member-apps. I believe that
> these are only used by one tool, and primarily to determine if there
> is a collision. In these days of terabyte hard drives, it isn't a
> huge issue for me, but may be for others.
>
> > > Also there does not seem to be a visual editor included in the docker
> > > build.
> > > > > (I had to use sed)
> > > > > It would be useful to have vi(m) or such.
> > >
> > > I've been doing an "apt install vim" when needed, but, yes, it would
> > > be nice to have vim already installed. There probably are a lot of
> > > affordances that would be helpful. At one point I tried an "apachectl
> > > status" and that failed as there wasn't a browser installed that it
> > > could use to fetch the status. I no longer recall what other commands
> > > I tried to use to check network status and the like only to find that
> > > they weren't installed.
> > >
> > > - Sam Ruby
> > >
> > > P.S. Thanks for helping work through this!
>
> - Sam Ruby
>
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by Matt Sicker <bo...@gmail.com>.
For the /srv checkouts, if you make them volumes, you can override that at
runtime to use a bound directory instead of a generic Docker volume (which
itself just goes in Docker’s data directory otherwise). Using a volume is
important regardless for file system performance on that data.
As for keeping the data format in sync, if that changes again in
the future, update the checkout instructions to use the appropriate feature
flag to use the old file format.
On Tue, Nov 19, 2019 at 14:35 sebb <se...@gmail.com> wrote:
> On Tue, 19 Nov 2019 at 17:49, Sam Ruby <ru...@intertwingly.net> wrote:
>
> > On Tue, Nov 19, 2019 at 9:15 AM sebb <se...@gmail.com> wrote:
> > >
> > > On Tue, 19 Nov 2019 at 13:34, Sam Ruby <ru...@intertwingly.net> wrote:
> > >
> > > > On Tue, Nov 19, 2019 at 8:17 AM sebb <se...@gmail.com> wrote:
> > > > >
> > > > > On Tue, 19 Nov 2019 at 12:26, sebb <se...@gmail.com> wrote:
> > > > >
> > > > > > docker:update had issues pulling down various svn repos, e.g.
> > > > > >
> > > > > > svn: E170013: Unable to connect to a repository at URL ...
> > > > > > svn: E125009: Invalid config: unable to load certificate file
> > > > > > '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
> > > > > >
> > > > > > I was able to remove the Invalid config error by changing
> > /Users/sebb
> > > > =>
> > > > > > /root
> > > > > > However I then got the error:
> > > > > >
> > > > > > svn: E000111: Error running context: Connection refused
> > > > > >
> > > > > > I assume that is because my SVN is set to grab passwords from the
> > macOS
> > > > > > keychain
> > > > > >
> > > > > >
> > > > > Turns out that SVN was down at the time.
> > > > >
> > > > > Once I copied the cert to the expected place it worked OK.
> > > > >
> > > > > I've just realised that the /srv/svn directory is mounted from the
> > host
> > > > OS.
> > > > > So checkouts in the image actually update the host working
> directory.
> > > > > Given that, it seems to me it would make more sense to do the
> > check-out
> > > > on
> > > > > the host under /srv, and mount that instead.
> > > >
> > > > Two issues:
> > > >
> > > > 1) From time to time subversion makes changes to the file format. It
> > > > could be the case that the version of subversion you have on the host
> > > > is not compatible with the version of subversion in the container.
> > > >
> > >
> > > In which case having the checkout on the host filing system is risky.
> > > It would be safer to have the data all within the container, and not
> > > accessible from the host.
> > > AFAICT it should not take any more space overall.
> >
> > It's complicated, and a lot depends on what the use cases we intend to
> > support are.
> >
> > For now, I've updated the Dockerfile to install a compatible version
> > of subversion, and updated DOCKER.md to explain the constraints.
> >
> > I actually developed these files using the /srv directory from the
> > MACOSX instructions.
> >
> > My thoughts are that most people would feel more comfortable doing
> > their browsing and updates in the host environment, so a shared mount
> > would be in order.
> >
> >
> OK
>
>
> > I definitely would not want to put repository data in images as those
> > are frozen (i.e., updates would be done in separate layers and would
> > take up more space). Similarly, I would not want to put repository
> > data in container space as those go away when the container exits.
> >
>
> I see.
>
>
> > Putting this data into a docker volume would work (and may be faster),
> > but may be less convenient for people that want to access the data
> > from their host.
> >
> > These constraints are particularly true for the whimsy directory. I'm
> > comfortable exec'ing into the container and editing the files using
> > vim, but others may want to use their Mac IDEs.
> >
> >
> Good point.
>
>
> > > But for those who can cope with the possible issue, there could be
> > another
> > > build that uses host data under /svn
> >
> > I do most of my whimsy work on my Ubuntu desktop machine, but I
> > recently updated the MACOSX instructions and have this working on my
> > laptop. I'm more likely to use those instructions than the container
> > instructions, but being able to share a /srv directory would be
> > convenient for me, allowing me to switch between the two.
> >
> > > 2) Doing the checkout on the host only defers the problem. A number
> > > > of whimsy processes access svn (checkouts and commits).
> > > >
> > > >
> > > It might be useful to be able to disable commits for testing purposes.
> > > This is also true of LDAP.
> >
> > Agreed, though for testing purposes I have defined a locally hosted
> > subversion repository for the board agenda tests, allowing commits to
> > be tested.
> >
> > > Regarding the SVN checkouts, maybe it would make sense to start by
> > checking
> > > out only the top-level files/directories for some of the
> less-used/larger
> > > trees.
> >
> > The largest are iclas, cclas, grants, and member-apps. I believe that
> > these are only used by one tool, and primarily to determine if there
> > is a collision. In these days of terabyte hard drives, it isn't a
> > huge issue for me, but may be for others.
> >
> >
> It's also a lot of data to download, and there might need to be a separate
> copy if the host version cannot be shared.
>
> In the case of iclas, I wrote a script to list the SVN repo contents and
> create empty files/directories locally.
> This works well with an empty checkout.
>
>
> > > Also there does not seem to be a visual editor included in the docker
> > > > build.
> > > > > > (I had to use sed)
> > > > > > It would be useful to have vi(m) or such.
> > > >
> > > > I've been doing an "apt install vim" when needed, but, yes, it would
> > > > be nice to have vim already installed. There probably are a lot of
> > > > affordances that would be helpful. At one point I tried an
> "apachectl
> > > > status" and that failed as there wasn't a browser installed that it
> > > > could use to fetch the status. I no longer recall what other
> commands
> > > > I tried to use to check network status and the like only to find that
> > > > they weren't installed.
> > > >
> > > > - Sam Ruby
> > > >
> > > > P.S. Thanks for helping work through this!
> >
> > - Sam Ruby
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by sebb <se...@gmail.com>.
On Tue, 19 Nov 2019 at 17:49, Sam Ruby <ru...@intertwingly.net> wrote:
> On Tue, Nov 19, 2019 at 9:15 AM sebb <se...@gmail.com> wrote:
> >
> > On Tue, 19 Nov 2019 at 13:34, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > > On Tue, Nov 19, 2019 at 8:17 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > On Tue, 19 Nov 2019 at 12:26, sebb <se...@gmail.com> wrote:
> > > >
> > > > > docker:update had issues pulling down various svn repos, e.g.
> > > > >
> > > > > svn: E170013: Unable to connect to a repository at URL ...
> > > > > svn: E125009: Invalid config: unable to load certificate file
> > > > > '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
> > > > >
> > > > > I was able to remove the Invalid config error by changing
> /Users/sebb
> > > =>
> > > > > /root
> > > > > However I then got the error:
> > > > >
> > > > > svn: E000111: Error running context: Connection refused
> > > > >
> > > > > I assume that is because my SVN is set to grab passwords from the
> macOS
> > > > > keychain
> > > > >
> > > > >
> > > > Turns out that SVN was down at the time.
> > > >
> > > > Once I copied the cert to the expected place it worked OK.
> > > >
> > > > I've just realised that the /srv/svn directory is mounted from the
> host
> > > OS.
> > > > So checkouts in the image actually update the host working directory.
> > > > Given that, it seems to me it would make more sense to do the
> check-out
> > > on
> > > > the host under /srv, and mount that instead.
> > >
> > > Two issues:
> > >
> > > 1) From time to time subversion makes changes to the file format. It
> > > could be the case that the version of subversion you have on the host
> > > is not compatible with the version of subversion in the container.
> > >
> >
> > In which case having the checkout on the host filing system is risky.
> > It would be safer to have the data all within the container, and not
> > accessible from the host.
> > AFAICT it should not take any more space overall.
>
> It's complicated, and a lot depends on what the use cases we intend to
> support are.
>
> For now, I've updated the Dockerfile to install a compatible version
> of subversion, and updated DOCKER.md to explain the constraints.
>
> I actually developed these files using the /srv directory from the
> MACOSX instructions.
>
> My thoughts are that most people would feel more comfortable doing
> their browsing and updates in the host environment, so a shared mount
> would be in order.
>
>
OK
> I definitely would not want to put repository data in images as those
> are frozen (i.e., updates would be done in separate layers and would
> take up more space). Similarly, I would not want to put repository
> data in container space as those go away when the container exits.
>
I see.
> Putting this data into a docker volume would work (and may be faster),
> but may be less convenient for people that want to access the data
> from their host.
>
> These constraints are particularly true for the whimsy directory. I'm
> comfortable exec'ing into the container and editing the files using
> vim, but others may want to use their Mac IDEs.
>
>
Good point.
> > But for those who can cope with the possible issue, there could be
> another
> > build that uses host data under /svn
>
> I do most of my whimsy work on my Ubuntu desktop machine, but I
> recently updated the MACOSX instructions and have this working on my
> laptop. I'm more likely to use those instructions than the container
> instructions, but being able to share a /srv directory would be
> convenient for me, allowing me to switch between the two.
>
> > 2) Doing the checkout on the host only defers the problem. A number
> > > of whimsy processes access svn (checkouts and commits).
> > >
> > >
> > It might be useful to be able to disable commits for testing purposes.
> > This is also true of LDAP.
>
> Agreed, though for testing purposes I have defined a locally hosted
> subversion repository for the board agenda tests, allowing commits to
> be tested.
>
> > Regarding the SVN checkouts, maybe it would make sense to start by
> checking
> > out only the top-level files/directories for some of the less-used/larger
> > trees.
>
> The largest are iclas, cclas, grants, and member-apps. I believe that
> these are only used by one tool, and primarily to determine if there
> is a collision. In these days of terabyte hard drives, it isn't a
> huge issue for me, but may be for others.
>
>
It's also a lot of data to download, and there might need to be a separate
copy if the host version cannot be shared.
In the case of iclas, I wrote a script to list the SVN repo contents and
create empty files/directories locally.
This works well with an empty checkout.
> > Also there does not seem to be a visual editor included in the docker
> > > build.
> > > > > (I had to use sed)
> > > > > It would be useful to have vi(m) or such.
> > >
> > > I've been doing an "apt install vim" when needed, but, yes, it would
> > > be nice to have vim already installed. There probably are a lot of
> > > affordances that would be helpful. At one point I tried an "apachectl
> > > status" and that failed as there wasn't a browser installed that it
> > > could use to fetch the status. I no longer recall what other commands
> > > I tried to use to check network status and the like only to find that
> > > they weren't installed.
> > >
> > > - Sam Ruby
> > >
> > > P.S. Thanks for helping work through this!
>
> - Sam Ruby
>
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Nov 19, 2019 at 9:15 AM sebb <se...@gmail.com> wrote:
>
> On Tue, 19 Nov 2019 at 13:34, Sam Ruby <ru...@intertwingly.net> wrote:
>
> > On Tue, Nov 19, 2019 at 8:17 AM sebb <se...@gmail.com> wrote:
> > >
> > > On Tue, 19 Nov 2019 at 12:26, sebb <se...@gmail.com> wrote:
> > >
> > > > docker:update had issues pulling down various svn repos, e.g.
> > > >
> > > > svn: E170013: Unable to connect to a repository at URL ...
> > > > svn: E125009: Invalid config: unable to load certificate file
> > > > '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
> > > >
> > > > I was able to remove the Invalid config error by changing /Users/sebb
> > =>
> > > > /root
> > > > However I then got the error:
> > > >
> > > > svn: E000111: Error running context: Connection refused
> > > >
> > > > I assume that is because my SVN is set to grab passwords from the macOS
> > > > keychain
> > > >
> > > >
> > > Turns out that SVN was down at the time.
> > >
> > > Once I copied the cert to the expected place it worked OK.
> > >
> > > I've just realised that the /srv/svn directory is mounted from the host
> > OS.
> > > So checkouts in the image actually update the host working directory.
> > > Given that, it seems to me it would make more sense to do the check-out
> > on
> > > the host under /srv, and mount that instead.
> >
> > Two issues:
> >
> > 1) From time to time subversion makes changes to the file format. It
> > could be the case that the version of subversion you have on the host
> > is not compatible with the version of subversion in the container.
> >
>
> In which case having the checkout on the host filing system is risky.
> It would be safer to have the data all within the container, and not
> accessible from the host.
> AFAICT it should not take any more space overall.
It's complicated, and a lot depends on what the use cases we intend to
support are.
For now, I've updated the Dockerfile to install a compatible version
of subversion, and updated DOCKER.md to explain the constraints.
I actually developed these files using the /srv directory from the
MACOSX instructions.
My thoughts are that most people would feel more comfortable doing
their browsing and updates in the host environment, so a shared mount
would be in order.
I definitely would not want to put repository data in images as those
are frozen (i.e., updates would be done in separate layers and would
take up more space). Similarly, I would not want to put repository
data in container space as those go away when the container exits.
Putting this data into a docker volume would work (and may be faster),
but may be less convenient for people that want to access the data
from their host.
These constraints are particularly true for the whimsy directory. I'm
comfortable exec'ing into the container and editing the files using
vim, but others may want to use their Mac IDEs.
> But for those who can cope with the possible issue, there could be another
> build that uses host data under /svn
I do most of my whimsy work on my Ubuntu desktop machine, but I
recently updated the MACOSX instructions and have this working on my
laptop. I'm more likely to use those instructions than the container
instructions, but being able to share a /srv directory would be
convenient for me, allowing me to switch between the two.
> 2) Doing the checkout on the host only defers the problem. A number
> > of whimsy processes access svn (checkouts and commits).
> >
> >
> It might be useful to be able to disable commits for testing purposes.
> This is also true of LDAP.
Agreed, though for testing purposes I have defined a locally hosted
subversion repository for the board agenda tests, allowing commits to
be tested.
> Regarding the SVN checkouts, maybe it would make sense to start by checking
> out only the top-level files/directories for some of the less-used/larger
> trees.
The largest are iclas, cclas, grants, and member-apps. I believe that
these are only used by one tool, and primarily to determine if there
is a collision. In these days of terabyte hard drives, it isn't a
huge issue for me, but may be for others.
> > Also there does not seem to be a visual editor included in the docker
> > build.
> > > > (I had to use sed)
> > > > It would be useful to have vi(m) or such.
> >
> > I've been doing an "apt install vim" when needed, but, yes, it would
> > be nice to have vim already installed. There probably are a lot of
> > affordances that would be helpful. At one point I tried an "apachectl
> > status" and that failed as there wasn't a browser installed that it
> > could use to fetch the status. I no longer recall what other commands
> > I tried to use to check network status and the like only to find that
> > they weren't installed.
> >
> > - Sam Ruby
> >
> > P.S. Thanks for helping work through this!
- Sam Ruby
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by sebb <se...@gmail.com>.
On Tue, 19 Nov 2019 at 13:34, Sam Ruby <ru...@intertwingly.net> wrote:
> On Tue, Nov 19, 2019 at 8:17 AM sebb <se...@gmail.com> wrote:
> >
> > On Tue, 19 Nov 2019 at 12:26, sebb <se...@gmail.com> wrote:
> >
> > > docker:update had issues pulling down various svn repos, e.g.
> > >
> > > svn: E170013: Unable to connect to a repository at URL ...
> > > svn: E125009: Invalid config: unable to load certificate file
> > > '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
> > >
> > > I was able to remove the Invalid config error by changing /Users/sebb
> =>
> > > /root
> > > However I then got the error:
> > >
> > > svn: E000111: Error running context: Connection refused
> > >
> > > I assume that is because my SVN is set to grab passwords from the macOS
> > > keychain
> > >
> > >
> > Turns out that SVN was down at the time.
> >
> > Once I copied the cert to the expected place it worked OK.
> >
> > I've just realised that the /srv/svn directory is mounted from the host
> OS.
> > So checkouts in the image actually update the host working directory.
> > Given that, it seems to me it would make more sense to do the check-out
> on
> > the host under /srv, and mount that instead.
>
> Two issues:
>
> 1) From time to time subversion makes changes to the file format. It
> could be the case that the version of subversion you have on the host
> is not compatible with the version of subversion in the container.
>
In which case having the checkout on the host filing system is risky.
It would be safer to have the data all within the container, and not
accessible from the host.
AFAICT it should not take any more space overall.
But for those who can cope with the possible issue, there could be another
build that uses host data under /svn
2) Doing the checkout on the host only defers the problem. A number
> of whimsy processes access svn (checkouts and commits).
>
>
It might be useful to be able to disable commits for testing purposes.
This is also true of LDAP.
Regarding the SVN checkouts, maybe it would make sense to start by checking
out only the top-level files/directories for some of the less-used/larger
trees.
> Also there does not seem to be a visual editor included in the docker
> build.
> > > (I had to use sed)
> > > It would be useful to have vi(m) or such.
>
> I've been doing an "apt install vim" when needed, but, yes, it would
> be nice to have vim already installed. There probably are a lot of
> affordances that would be helpful. At one point I tried an "apachectl
> status" and that failed as there wasn't a browser installed that it
> could use to fetch the status. I no longer recall what other commands
> I tried to use to check network status and the like only to find that
> they weren't installed.
>
> - Sam Ruby
>
> P.S. Thanks for helping work through this!
>
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Nov 19, 2019 at 8:17 AM sebb <se...@gmail.com> wrote:
>
> On Tue, 19 Nov 2019 at 12:26, sebb <se...@gmail.com> wrote:
>
> > docker:update had issues pulling down various svn repos, e.g.
> >
> > svn: E170013: Unable to connect to a repository at URL ...
> > svn: E125009: Invalid config: unable to load certificate file
> > '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
> >
> > I was able to remove the Invalid config error by changing /Users/sebb =>
> > /root
> > However I then got the error:
> >
> > svn: E000111: Error running context: Connection refused
> >
> > I assume that is because my SVN is set to grab passwords from the macOS
> > keychain
> >
> >
> Turns out that SVN was down at the time.
>
> Once I copied the cert to the expected place it worked OK.
>
> I've just realised that the /srv/svn directory is mounted from the host OS.
> So checkouts in the image actually update the host working directory.
> Given that, it seems to me it would make more sense to do the check-out on
> the host under /srv, and mount that instead.
Two issues:
1) From time to time subversion makes changes to the file format. It
could be the case that the version of subversion you have on the host
is not compatible with the version of subversion in the container.
2) Doing the checkout on the host only defers the problem. A number
of whimsy processes access svn (checkouts and commits).
> Also there does not seem to be a visual editor included in the docker build.
> > (I had to use sed)
> > It would be useful to have vi(m) or such.
I've been doing an "apt install vim" when needed, but, yes, it would
be nice to have vim already installed. There probably are a lot of
affordances that would be helpful. At one point I tried an "apachectl
status" and that failed as there wasn't a browser installed that it
could use to fetch the status. I no longer recall what other commands
I tried to use to check network status and the like only to find that
they weren't installed.
- Sam Ruby
P.S. Thanks for helping work through this!
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by sebb <se...@gmail.com>.
On Tue, 19 Nov 2019 at 12:26, sebb <se...@gmail.com> wrote:
> docker:update had issues pulling down various svn repos, e.g.
>
> svn: E170013: Unable to connect to a repository at URL ...
> svn: E125009: Invalid config: unable to load certificate file
> '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
>
> I was able to remove the Invalid config error by changing /Users/sebb =>
> /root
> However I then got the error:
>
> svn: E000111: Error running context: Connection refused
>
> I assume that is because my SVN is set to grab passwords from the macOS
> keychain
>
>
Turns out that SVN was down at the time.
Once I copied the cert to the expected place it worked OK.
I've just realised that the /srv/svn directory is mounted from the host OS.
So checkouts in the image actually update the host working directory.
Given that, it seems to me it would make more sense to do the check-out on
the host under /srv, and mount that instead.
Also there does not seem to be a visual editor included in the docker build.
> (I had to use sed)
> It would be useful to have vi(m) or such.
>
> S.
> On Tue, 19 Nov 2019 at 03:24, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> On Sat, Oct 19, 2019 at 12:43 AM Dave Fisher <wa...@comcast.net>
>> wrote:
>> >
>> > Maybe a docker image is the way to go. I’ll test it if you point it out.
>>
>> Beta testers wanted:
>> https://github.com/apache/whimsy/blob/master/DOCKER.md
>>
>> - Sam Ruby
>>
>
Re: Docker beta testers wanted (was: Mac OSX read only file system)
Posted by sebb <se...@gmail.com>.
docker:update had issues pulling down various svn repos, e.g.
svn: E170013: Unable to connect to a repository at URL ...
svn: E125009: Invalid config: unable to load certificate file
'/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem'
I was able to remove the Invalid config error by changing /Users/sebb =>
/root
However I then got the error:
svn: E000111: Error running context: Connection refused
I assume that is because my SVN is set to grab passwords from the macOS
keychain
Also there does not seem to be a visual editor included in the docker build.
(I had to use sed)
It would be useful to have vi(m) or such.
S.
On Tue, 19 Nov 2019 at 03:24, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Oct 19, 2019 at 12:43 AM Dave Fisher <wa...@comcast.net>
> wrote:
> >
> > Maybe a docker image is the way to go. I’ll test it if you point it out.
>
> Beta testers wanted:
> https://github.com/apache/whimsy/blob/master/DOCKER.md
>
> - Sam Ruby
>
Docker beta testers wanted (was: Mac OSX read only file system)
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Oct 19, 2019 at 12:43 AM Dave Fisher <wa...@comcast.net> wrote:
>
> Maybe a docker image is the way to go. I’ll test it if you point it out.
Beta testers wanted: https://github.com/apache/whimsy/blob/master/DOCKER.md
- Sam Ruby
Re: Mac OSX read only file system
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Oct 19, 2019 at 6:39 AM Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Sat, Oct 19, 2019 at 12:43 AM Dave Fisher <wa...@comcast.net> wrote:
> >
> > Maybe a docker image is the way to go. I’ll test it if you point it out.
>
> A docker image is VERY appealing. There are things that don't work
> and/or are hard to do on Mac (for example, setting up Apache httpd
> with LDAP enabled as brew no longer supports that). And there would
> be the added benefit of having the development environment more
> closely match the deployment environment.
>
> Two issues:
>
> 1) We would need to work through how to get your users git and
> subversion credentials onto the container. This is solvable.
>
> 2) Mounted file systems are fast only on Linux. On Mac and Windows,
> they are dog slow. This likely means that the way to go is have the
> /srv directory in a container. Faster, but less convenient. At the
> moment, a full /srv directory is 29G. Perhaps the container could run
> something like nfs enabling the host to mount it?
I'm starting to look at this and things are a bit more promising than
the last time I looked at Docker. In particular, mounted file system
performance has improved significantly, and docker-compose can deal
with much of the configuration stuff (e.g. volume mounts).
Current thoughts:
* Docker works best with static data in the images and all persistent
data in volumes (i.e., no transient data in containers). We nearly
have that split now with the /srv directory being the persistent data
(including whimsy source!) and nearly everything else being static.
The one thing that I would consider adding to the volume is the
installed gems as that is something a developer may wish to add to.
This can be done by setting the GEM_HOME environment variable to
/srv/gems in the Dockerfile.
* The developer model would be roughly thus: create an empty directory
in that directory clone the whimsy source. Change directory into that
source and run a command like "rake docker:build" to build the image,
and "rake docker:update" to populate the "/srv" directory. As the
/srv directory will be mounted on the parent directory of the whimsy
source, these files will reside on the host computer, and one can use
your favorite IDE or editor on this data. "rake docker:run" and "rake
docker:stop" could start and stop a web server which could be accessed
at a predefined port number.
* Down the road, it may make sense to provide options to allow
directories like iclas, grants, cclas, and member_apps to be skipped,
as these are primarily for a single tool (the secretary workbench) and
currently are over 22G. The remainder of the srv directory is
currently under 7G. I don't yet know how big the image itself will
need to be, I'd guess a few G.
* For users who have ssh access to whimsy.apache.org, it may also be
worth adding commands that will selectively rsync various directories
from whimsy.apache.org to the host directory containing the
container's /srv directory. I do this frequently when I debug board
agenda issues.
Net-net: a person with a developer class laptop with 10G of available
space and a good internet connection could get up and running with a
few commands. All they would need to have installed is docker and
git. They could make local changes, see the results in their browser,
and commit and push the changes once they are happy with the result.
Should even work on Windows.
- Sam Ruby
Re: Mac OSX read only file system
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Oct 19, 2019 at 12:43 AM Dave Fisher <wa...@comcast.net> wrote:
>
> Maybe a docker image is the way to go. I’ll test it if you point it out.
A docker image is VERY appealing. There are things that don't work
and/or are hard to do on Mac (for example, setting up Apache httpd
with LDAP enabled as brew no longer supports that). And there would
be the added benefit of having the development environment more
closely match the deployment environment.
Two issues:
1) We would need to work through how to get your users git and
subversion credentials onto the container. This is solvable.
2) Mounted file systems are fast only on Linux. On Mac and Windows,
they are dog slow. This likely means that the way to go is have the
/srv directory in a container. Faster, but less convenient. At the
moment, a full /srv directory is 29G. Perhaps the container could run
something like nfs enabling the host to mount it?
- Sam Ruby
Re: Mac OSX read only file system
Posted by Dave Fisher <wa...@comcast.net>.
Catalina did some annoying things. For me emacs was gone as Apple doesn’t like gpl3.
There is more security on directories.
Maybe a docker image is the way to go. I’ll test it if you point it out.
Sent from my iPhone
> On Oct 18, 2019, at 9:05 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> With the latest update (Catalina):
>
> $ sudo mkdir /srv
> mkdir: /srv: Read-only file system
>
> Previously, whimsy tools were set up to determine file names based on
> a ~/.whimsy config file. Over time, much of this has changed to
> presume /srv. Most problematic:
>
> $LOAD_PATH.unshift '/srv/whimsy/lib'
>
> Not sure what the solution would be.
>
> - Sam Ruby
Re: Mac OSX read only file system
Posted by sebb <se...@gmail.com>.
On Sat, 19 Oct 2019 at 12:01, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Sat, Oct 19, 2019 at 5:00 AM sebb <se...@gmail.com> wrote:
> >
> > Also /srv is actually a link to /x1/srv on Ubuntu, so potentially it
> > could be changed in stages?
>
> There is no /srv directory. There is no /x1 directory. And neither
> can be created. There are two volumes. The root volume is read only.
> /System/Volumes/Data is read write.
>
> $ df
> Filesystem 512-blocks Used Available Capacity iused
> ifree %iused Mounted on
> /dev/disk1s5 1953595632 21525144 1596741216 2% 481690
> 9767496470 0% /
> devfs 405 405 0 100% 712
> 0 100% /dev
> /dev/disk1s1 1953595632 325337392 1596741216 17% 2170102
> 9765808058 0% /System/Volumes/Data
> /dev/disk1s4 1953595632 6293544 1596741216 1% 4
> 9767978156 0% /private/var/vm
> map auto_home 0 0 0 100% 0
> 0 100% /System/Volumes/Data/home
>
> $ ls -al /
> total 9
> drwxr-xr-x 23 root admin 736 Oct 18 10:24 .
> drwxrwxrwx 3 root wheel 96 Sep 7 12:05 .%cb_defense
> drwxr-xr-x 23 root admin 736 Oct 18 10:24 ..
> -rw-rw-r-- 1 root admin 0 Aug 24 18:20 .DS_Store
> lrwxr-xr-x 1 root admin 36 Oct 11 14:53 .VolumeIcon.icns ->
> System/Volumes/Data/.VolumeIcon.icns
> ---------- 1 root admin 0 Aug 24 18:20 .file
> drwx------ 11 root admin 352 Oct 18 10:29 .fseventsd
> drwxr-xr-x 2 root wheel 64 Aug 24 18:20 .vol
> drwxrwxr-x+ 30 root admin 960 Oct 18 23:14 Applications
> drwxr-xr-x 68 root wheel 2176 Oct 18 10:26 Library
> drwxr-xr-x@ 8 root wheel 256 Sep 29 16:23 System
> drwxr-xr-x 6 root admin 192 Sep 29 16:22 Users
> drwxr-xr-x 3 root wheel 96 Oct 18 22:11 Volumes
> drwxr-xr-x@ 38 root wheel 1216 Sep 29 16:28 bin
> drwxr-xr-x 2 root wheel 64 Aug 24 18:24 cores
> dr-xr-xr-x 3 root wheel 4541 Oct 18 10:29 dev
> lrwxr-xr-x@ 1 root admin 11 Oct 11 14:46 etc -> private/etc
> lrwxr-xr-x 1 root wheel 25 Oct 18 10:30 home -> /System/Volumes/Data/home
> drwxr-xr-x 4 root wheel 128 Oct 11 14:59 opt
> drwxr-xr-x 6 root wheel 192 Oct 18 10:25 private
> drwxr-xr-x@ 64 root wheel 2048 Oct 11 14:53 sbin
> lrwxr-xr-x@ 1 root admin 11 Oct 11 14:53 tmp -> private/tmp
> drwxr-xr-x@ 11 root wheel 352 Oct 11 14:53 usr
> lrwxr-xr-x@ 1 root admin 11 Oct 11 14:53 var -> private/var
>
> I can't seem to make a /home/whimsy directory (" Operation not
> supported"),
That may be possible if you mount a container over it (assuming /home is empty).
If /home now contains HOME directories, maybe try creating a whimsy user?
> but I can make a /var/whimsy directory. Perhaps on
> Ubuntu we could make ./var/whimsy a symlink to /x1/xrv and then
> migrate to that?
+1
Hopefully less likely that /var/whimsy will ever be reserved, or /var
itself restricted or renamed...
> Sam Ruby
Re: Mac OSX read only file system
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Oct 19, 2019 at 5:00 AM sebb <se...@gmail.com> wrote:
>
> Also /srv is actually a link to /x1/srv on Ubuntu, so potentially it
> could be changed in stages?
There is no /srv directory. There is no /x1 directory. And neither
can be created. There are two volumes. The root volume is read only.
/System/Volumes/Data is read write.
$ df
Filesystem 512-blocks Used Available Capacity iused
ifree %iused Mounted on
/dev/disk1s5 1953595632 21525144 1596741216 2% 481690
9767496470 0% /
devfs 405 405 0 100% 712
0 100% /dev
/dev/disk1s1 1953595632 325337392 1596741216 17% 2170102
9765808058 0% /System/Volumes/Data
/dev/disk1s4 1953595632 6293544 1596741216 1% 4
9767978156 0% /private/var/vm
map auto_home 0 0 0 100% 0
0 100% /System/Volumes/Data/home
$ ls -al /
total 9
drwxr-xr-x 23 root admin 736 Oct 18 10:24 .
drwxrwxrwx 3 root wheel 96 Sep 7 12:05 .%cb_defense
drwxr-xr-x 23 root admin 736 Oct 18 10:24 ..
-rw-rw-r-- 1 root admin 0 Aug 24 18:20 .DS_Store
lrwxr-xr-x 1 root admin 36 Oct 11 14:53 .VolumeIcon.icns ->
System/Volumes/Data/.VolumeIcon.icns
---------- 1 root admin 0 Aug 24 18:20 .file
drwx------ 11 root admin 352 Oct 18 10:29 .fseventsd
drwxr-xr-x 2 root wheel 64 Aug 24 18:20 .vol
drwxrwxr-x+ 30 root admin 960 Oct 18 23:14 Applications
drwxr-xr-x 68 root wheel 2176 Oct 18 10:26 Library
drwxr-xr-x@ 8 root wheel 256 Sep 29 16:23 System
drwxr-xr-x 6 root admin 192 Sep 29 16:22 Users
drwxr-xr-x 3 root wheel 96 Oct 18 22:11 Volumes
drwxr-xr-x@ 38 root wheel 1216 Sep 29 16:28 bin
drwxr-xr-x 2 root wheel 64 Aug 24 18:24 cores
dr-xr-xr-x 3 root wheel 4541 Oct 18 10:29 dev
lrwxr-xr-x@ 1 root admin 11 Oct 11 14:46 etc -> private/etc
lrwxr-xr-x 1 root wheel 25 Oct 18 10:30 home -> /System/Volumes/Data/home
drwxr-xr-x 4 root wheel 128 Oct 11 14:59 opt
drwxr-xr-x 6 root wheel 192 Oct 18 10:25 private
drwxr-xr-x@ 64 root wheel 2048 Oct 11 14:53 sbin
lrwxr-xr-x@ 1 root admin 11 Oct 11 14:53 tmp -> private/tmp
drwxr-xr-x@ 11 root wheel 352 Oct 11 14:53 usr
lrwxr-xr-x@ 1 root admin 11 Oct 11 14:53 var -> private/var
I can't seem to make a /home/whimsy directory (" Operation not
supported"), but I can make a /var/whimsy directory. Perhaps on
Ubuntu we could make ./var/whimsy a symlink to /x1/xrv and then
migrate to that?
- Sam Ruby
Re: Mac OSX read only file system
Posted by sebb <se...@gmail.com>.
Also /srv is actually a link to /x1/srv on Ubuntu, so potentially it
could be changed in stages?
On Sat, 19 Oct 2019 at 09:53, sebb <se...@gmail.com> wrote:
>
> Does /srv contain anything?
>
> Or is it an empty directory like /home?
>
> If it's empty, then I found out that it's possible to mount a container over it.
>
> S.
>
> On Sat, 19 Oct 2019 at 05:44, Dave Fisher <wa...@comcast.net> wrote:
> >
> > Or is chmod your friend?
> >
> > Sent from my iPhone
> >
> > > On Oct 18, 2019, at 9:05 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> > >
> > > With the latest update (Catalina):
> > >
> > > $ sudo mkdir /srv
> > > mkdir: /srv: Read-only file system
> > >
> > > Previously, whimsy tools were set up to determine file names based on
> > > a ~/.whimsy config file. Over time, much of this has changed to
> > > presume /srv. Most problematic:
> > >
> > > $LOAD_PATH.unshift '/srv/whimsy/lib'
> > >
> > > Not sure what the solution would be.
> > >
> > > - Sam Ruby
Re: Mac OSX read only file system
Posted by sebb <se...@gmail.com>.
Does /srv contain anything?
Or is it an empty directory like /home?
If it's empty, then I found out that it's possible to mount a container over it.
S.
On Sat, 19 Oct 2019 at 05:44, Dave Fisher <wa...@comcast.net> wrote:
>
> Or is chmod your friend?
>
> Sent from my iPhone
>
> > On Oct 18, 2019, at 9:05 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > With the latest update (Catalina):
> >
> > $ sudo mkdir /srv
> > mkdir: /srv: Read-only file system
> >
> > Previously, whimsy tools were set up to determine file names based on
> > a ~/.whimsy config file. Over time, much of this has changed to
> > presume /srv. Most problematic:
> >
> > $LOAD_PATH.unshift '/srv/whimsy/lib'
> >
> > Not sure what the solution would be.
> >
> > - Sam Ruby
Re: Mac OSX read only file system
Posted by Dave Fisher <wa...@comcast.net>.
Or is chmod your friend?
Sent from my iPhone
> On Oct 18, 2019, at 9:05 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> With the latest update (Catalina):
>
> $ sudo mkdir /srv
> mkdir: /srv: Read-only file system
>
> Previously, whimsy tools were set up to determine file names based on
> a ~/.whimsy config file. Over time, much of this has changed to
> presume /srv. Most problematic:
>
> $LOAD_PATH.unshift '/srv/whimsy/lib'
>
> Not sure what the solution would be.
>
> - Sam Ruby
Re: Mac OSX read only file system
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, Oct 20, 2019 at 9:23 AM Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Sat, Oct 19, 2019 at 7:19 PM Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > P.S. Not a priority for me at this next week, but it occurs to me that
> > newer versions of MAC OS/X may have newer versions of Apache HTTPD, so
> > we may no longer need the brew version of Apache HTTPD, which these
> > days require manual patches to get working.
>
> On a lark, I went back to the old instructions and tried to follow them:
>
> https://github.com/apache/whimsy/blob/aabae97c6d3b9b88a08544edbeff5174c37a0d25/MACOSX.md#install-passenger
>
> Other than having to add PATH to org.apache.httpd.plist, it worked.
> I'm able to bring up site.cgi and the board agenda tool.
>
> $ curl --head whimsy.local
> HTTP/1.1 200 OK
> Date: Sun, 20 Oct 2019 13:00:56 GMT
> Server: Apache/2.4.41 (Unix) Phusion_Passenger/6.0.4
> Last-Modified: Sat, 10 Aug 2019 13:23:16 GMT
> ETag: "2a57-58fc33188d900"
> Accept-Ranges: bytes
> Content-Length: 10839
> Content-Type: text/html
Just a heads up - I wiped and did a fresh install of Mac OSX Catalina
on one of my machines, and I will be going through and cleaning up
(and hopefully streamlining!) most of the MACOSX.md instructions over
the next few days.
- Sam Ruby
Re: Mac OSX read only file system
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Oct 19, 2019 at 7:19 PM Sam Ruby <ru...@intertwingly.net> wrote:
>
> P.S. Not a priority for me at this next week, but it occurs to me that
> newer versions of MAC OS/X may have newer versions of Apache HTTPD, so
> we may no longer need the brew version of Apache HTTPD, which these
> days require manual patches to get working.
On a lark, I went back to the old instructions and tried to follow them:
https://github.com/apache/whimsy/blob/aabae97c6d3b9b88a08544edbeff5174c37a0d25/MACOSX.md#install-passenger
Other than having to add PATH to org.apache.httpd.plist, it worked.
I'm able to bring up site.cgi and the board agenda tool.
$ curl --head whimsy.local
HTTP/1.1 200 OK
Date: Sun, 20 Oct 2019 13:00:56 GMT
Server: Apache/2.4.41 (Unix) Phusion_Passenger/6.0.4
Last-Modified: Sat, 10 Aug 2019 13:23:16 GMT
ETag: "2a57-58fc33188d900"
Accept-Ranges: bytes
Content-Length: 10839
Content-Type: text/html
- Sam Ruby
Re: Mac OSX read only file system
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Oct 19, 2019 at 12:05 AM Sam Ruby <ru...@intertwingly.net> wrote:
>
> With the latest update (Catalina):
>
> $ sudo mkdir /srv
> mkdir: /srv: Read-only file system
>
> Previously, whimsy tools were set up to determine file names based on
> a ~/.whimsy config file. Over time, much of this has changed to
> presume /srv. Most problematic:
>
> $LOAD_PATH.unshift '/srv/whimsy/lib'
>
> Not sure what the solution would be.
Found a solution, and added it to the Whimsy MACOSX instructions:
https://github.com/apache/whimsy/blob/master/MACOSX.md#clone-the-whimsy-code
- Sam Ruby
P.S. Not a priority for me at this next week, but it occurs to me that
newer versions of MAC OS/X may have newer versions of Apache HTTPD, so
we may no longer need the brew version of Apache HTTPD, which these
days require manual patches to get working.