To set up SmokeDetector (SD), please execute the following commands:
git clone https://github.com/Charcoal-SE/SmokeDetector.git cd SmokeDetector git checkout deploy sudo pip3 install -r requirements.txt --upgrade pip3 install --user -r user_requirements.txt --upgrade
config.sample to a new file called
config, and edit the values required. If you are going to be running this SmokeDetector instance as a normal SD instance with metasmoke, see the “config” file with MS below.
You should now be able to run SmokeDetector.
You will need a keybase account. You will also need to have the “smoke detector runner” role on metasmoke (MS). Contact an MS admin to request the role. When given the role, you should separately be added to the “charcoal” channel on keybase.
In the files section for the keybase “charcoal” channel, there is a “config” file. You should use that config file as a basis for the “config” file you use in your “SmokeDetector” directory.
locationto the name you choose for your SD instance. This should be your username, followed by a slash and an identifier that’s unique among all your Smokey instances. This is the name that your instance will display in messages in chat and what will be displayed on MS for status.
If a file “rooms_custom.yml” exists in the SD directory, then it will be used instead of the “rooms.yml” file. If you are not running a full SD instance, which is reporting into Charcoal HQ and all other rooms, you will need to create a “rooms_custom.yml” which describes the rooms in which you want SD to be reporting and accepting commands. For more information about the format used in “rooms.yml” and “rooms_custom.yml”, please see: Rooms configuration.
At this point, you should be able to run SmokeDetector using the instructions below.
Using a AWS EC2 instance can be a quick way to get an SD instance up and running. Based on reports from @iBug in chat, a t2.micro instance, what’s available from the AWS Free Tier for 12 months, doesn’t have enough CPU credits for the instance to be the active SD instance full-time. It’s expected that a t3.micro, which actually costs less than a t2.micro, once past the free period, should be sufficient for a full-time active SD instance. However, a t2.micro instance does appear to be enough for SD to run as a standby instance to fill in on an irregular basis.
To set-up a t2.micro instance for SD you can do the following:
yum. Other versions may use
pacmanetc. In addition, other versions of Linux may already have versions of some of the packages installed in the commands below, or may be missing yet other packages. The commands listed below were only tested in the AMI mentioned above.
Execute the following commands. You can copy-&-paste all of them at one time. The commands above the blank line get your EC2 instance to where SmokeDetector can be installed (only tested in the AMI mentioned above). The commands below the blank line clone SmokeDetector from GitHub and install its Python dependencies (the commands below the blank line are a duplicate of those at the top of this page, but are included below to make copy-&-pasting easier):
sudo yum -y update sudo yum -y install gcc sudo yum -y install git sudo yum -y install python36 sudo yum -y install python36-devel sudo python3 -m pip install pip --upgrade git clone https://github.com/Charcoal-SE/SmokeDetector.git cd SmokeDetector git config user.email "[email protected]" git config user.name "SmokeDetector" git checkout deploy sudo /usr/local/bin/pip3 install -r requirements.txt --upgrade pip3 install --user -r user_requirements.txt --upgrade
config.sampleto a new file called
config, and edit the values required.
To run, use
python3 nocrash.py, or
python3 nocrash.py standby (preferably in a daemon-able mode, like a
You can also use
python3 ws.py, but then SmokeDetector will be shut down after 6 hours;
when running from
ws.py will automatically be restarted.
(This is to be sure that closed WebSockets, if any, are reopened.)
nocrash.py is the controlling Python code for SmokeDetector. It runs
ws.py, which is the SD instance, in a subprocess and restarts the SD instance when it stops.
ws.py may stop as the result of various chat
!!/ commands, or do to errors. The syntax for
nocrash.py [standby] [--loglevel=(debug|info|warning|error)] [no_se_activity_scan]
standby option starts the SD instance in standby mode.
no_se_activity_scan option causes the SD instance not to watch the SE WebSocket for new posts, even when the instance is active. This gives you an SD instance which will listen for commands in chat, but won’t be scanning for new posts, other than ones you
!!/report. If you are not testing something which is directly involved with scanning posts from the SE WebSocket (i.e. you don’t need to scan a large number of posts, or test/use the SE WebSocket and per-site post fetching queues), then using
no_se_activity_scan will probably be quite beneficial to you, as it will allow you to focus on what you are testing without seeing large amounts of output from scanning posts.
Portions of this page were taken from README.md.