Sponsored Content
The Lounge What is on Your Mind? Update on vB3 Migration to Discourse - Issues and Status of BBCode Transformations Post 303045854 by Neo on Wednesday 15th of April 2020 10:27:26 PM
Old 04-15-2020
Update:

Have made some core changes and am currently running both our staging server and our production server in "two container" mode; where the database and the web app are in two separate docker containers:

Update on vB3 Migration to Discourse - Issues and Status of BBCode Transformations-screen-shot-2020-04-16-91845-amjpg


My next plan is to set up ngnix as a reverse proxy on the staging server to a unix domain socket in the docker container, and decouple the network (TCP/IP) from the web app in the container.

This will permit us to completely rebuild the app, add new plugins, add custom code, etc. to the web app with almost zero down time because each container will have it's one unique shared (persistant) directory and we can symlink from outside the container to inside.

This means, for example, on nginx we can just change symlinks to move from one live container to the other.

OBTW, on apache (which we are not using in this setup), apache will not let us set up the proxy configuration with a symlink, so a restart of the web app is required. It's not a big deal; so if you are running apache and want to integrate these container-based web apps into your virtual host configurations, it is not a problem at all.

I have been doing these changes in a controlled, step-by-step manner, since these are "breaking changes". However, after all done. The site will be much more robust when we are done.

Honestly, I think the "two container" solution should be standard OOTB and it not "an advanced configuration" like Discourse meta says. It's actually straight forward and the best way to go and the setup is actually straight forward (two containers). The reverse proxy server to a unix domain socket is a bit more "advanced" so I do understand why folks call this "advanced" Smilie
This User Gave Thanks to Neo For This Post:
 

6 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Shell Script migration issues

Hi All, We will be doing a Solaris 8 to Solaris 10 migration migration, just wanted to know if there are any known / common issues arise from this migration from Shell script point of view. I tried searching this site but mostly post are related to SA's question and jumpstart, etc. If there's... (4 Replies)
Discussion started by: arvindcgi
4 Replies

2. HP-UX

Migration - Compiler Issues.

All, We are migrating an application from HP-UX B.11.00 to HP-UX B.11.31 and both of them have the same informix version - 7.25se. However the compilers are different on both servers. HP-UX B.11.00 - has B3913DB C.03.33 HP aC++ Compiler (S800) HP-UX B.11.31 - has PHSS_40631 1.0 HP C/aC++... (2 Replies)
Discussion started by: helper
2 Replies

3. Programming

How to track table status delete/update/insert status in DB2 V10 z/os?

Dear Team I am using DB2 v10 z/os database . Need expert guidance to figure out best way to track table activities ( Ex Delete, Insert,Update ) Scenario We have a table which is critical and many developer/testing team access on daily basis . We had instance where some deleted... (1 Reply)
Discussion started by: Perlbaby
1 Replies

4. What is on Your Mind?

Status of Migration of Moderation Systems

First a bit of history .... A number of years ago one of our admins built a number of plugin systems for moderation, including (1) a voting system, (2) a "user feelings" system and (3) a confidential posting system. During this time, I was busy on other projects, not very active in the forums,... (1 Reply)
Discussion started by: Neo
1 Replies

5. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Two

OK. Like we all do, we learn a lot from tests, test migrations, and so forth. Today, I started from scratch on test migration 2, armed with a lot more knowledge, The main differences are as follows: Installed discourse plugin ruby-bbcode-to-md before starting the install Modified... (30 Replies)
Discussion started by: Neo
30 Replies

6. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Four

Test Build 4 on New Server, with changes identified in discourse test builds 2 and 3, primarily: Insuring ruby-bbcode-to-markdown is enabled. Removing line breaks from ICODE to markdown in migration script. Added vbpostid to posts in discourse to setup migrating vb "thanks" to discourse... (28 Replies)
Discussion started by: Neo
28 Replies
asctl(1)						    BSD General Commands Manual 						  asctl(1)

NAME
asctl -- App Sandbox Control Tool SYNOPSIS
asctl [-p] [--container-path <path>] command [arguments] DESCRIPTION
Many commands require an application specification as one of their arguments. Applications can be specified any of the following ways: <name> The application name as it appears in the Applications folder, with or without the .app extension. For example, "TextEdit". <path> The path to the application binary or bundle. For example, "/Applications/TextEdit.app". --file <path> Explicitly indicate the following argument is to be interpreted as the path to the application binary or bundle. The --file flag removes ambiguity when an argument can be interpreted as either an application name or a valid path to an application. For example, "--file /Applications/TextEdit.app". --bundle <bundle Id> Interpret the following argument as the bunder identifier of the application. For example, "--bundle com.apple.TextEdit". --pid <process Id> Interpret the following argument as the process identifier of a running application. For example, "--pid 1". GENERAL COMMANDS
help Prints a summary of commands and their behaviours. sandbox check <app specification> Determines with the given application is signed with App Sandbox entitlements. In addition, if the application is specified by pid using the --pid syntax, prints out whether the application is actually running with App Sandbox enabled, a traditional sandbox, or no sandbox at all. CONTAINER MANAGEMENT COMMANDS
The following commands manage filesystem containers for sandboxed apps. container path <app specification> Print the path to the application's container. container create <app specification> Create and initialize the application's container. Containers are normally created automatically when sandboxed applications are run. This command creates the container for an application without running the application. container upgrade <app specification> Upgrade the application's container to the current container schema. Existing containers are normally automatically upgraded to the latest container schema when their associated applications are run. This command upgrades an existing container without running the associated application. CONTAINER ACL MANAGEMENT COMMANDS
Each container has an access control list comprised of code requirements. A sandboxed application must satify one or more of the code requirements on their container in order to run. The following commands manipulate the container's access control list: container acl add <app specification> Update the access control list for the application's container to include the application's designated code requirement. container acl add <app specification> <code requirement> Update the access control list for the application's container to include the specified code requirement. container acl update <app specification> Update the access control list for the application's container such that it consists of only the application's designated code requirement. Any other code requirements will be removed from the ACL. container acl list <app specification> Print list of code requirements in the access control list for the given application's container. container acl validate <app specification> Validate the application against each of the code requirements in its container's access control list. Each code requirement in the ACL is labeled with one of the following: [FAIL] application does not validate against code requirement. [VALID] application validates against code requirement. [EXACT] application validates against code requirement and code requirement is the same as the application's designated code requirement. container acl verify <app specification> Synonym for acl validate. SYMLINK SUPPORT COMMANDS
App Sandbox will follow any symlinks in the paths to users' home directories. In addition, it has a whitelist of other locations where it will acknowledge and honor symbolic links. Any symlinks not in this whitelist will not be followed and, as a result, App Sandboxed applica- tions will not have access to the paths that the symlinks refer to. The following command displays the whitelist of paths where App Sandbox will acknowledge symlinks at: symlink list <path ...> Display the list of paths that App Sandbox searches for symlinks and, for any paths that are symlinks, display where the symlinks currently resolve to. DIAGNOSTIC COMMAND
Collect diagnostic information related to Application Sandboxing and containers. The information is collected into a single file that can be sent to Apple to aid in diagnosing problems when an application runs inside of a sandbox. Should you choose to send the diagnostic informa- tion to Apple, then you must agree to this disclaimer: This diagnostic tool generates files that allow Apple to investigate issues with your computer and help Apple to improve its products. The generated files may contain some of your personal information, which may include, but not be limited to, the serial number or similar unique number for your device, your user name, your file names or your computer name. The information is used by Apple in accordance with its pri- vacy policy (www.apple.com/privacy) and is not shared with any third party. By enabling this diagnostic tool and sending a copy of the gen- erated files to Apple, you are consenting to Apple's use of the content of such files. Additional information concerning a specific application can be gathered via the app subcommand. This command must be run as 'root'. The following command collects diagnostic information: diagnose [--no-compress | --no-disclaimer | --no-reveal | --no-verbose] [app <app specification>] Collection diagnostic information. Outputs the path to the folder or file containing the information. Optional arguments: --no-compress Do not compress the folder containing the dianostic files into a Zip file. --no-disclaimer Do not show the disclaimer. Use of this option constitutes acceptance of the disclaimer. --no-reveal Do not reveal the resulting diagnostic file in Finder. --no-verbose Do not show verbose output while running the diagnostic. Optional subcommand: app <app specification> Specify an application for which additional information will be gathered. GLOBAL OPTIONS
-p By default, asctl displays paths relative to the user's home directory. This flag causes any paths in the output to be displayed as absolute paths instead. SEE ALSO
codesign(1) HISTORY
The asctl command first appeared in Mac OS X Version 10.7. BSD
February 7, 2012 BSD
All times are GMT -4. The time now is 09:35 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy