Maltfield Log/2020 Q1

From Open Source Ecology
Jump to navigation Jump to search

My work log from the year 2020 Quarter 1. I intentionally made this verbose to make future admin's work easier when troubleshooting. The more keywords, error messages, etc that are listed in this log, the more helpful it will be for the future OSE Sysadmin.

See Also

  1. Maltfield_Log
  2. User:Maltfield
  3. Special:Contributions/Maltfield

Thr Feb 13, 2020

  1. Ugh, I just got an (encrypted) email from OSSEC showing a diff of our cert.pem file that changed.
  2. I should have already disabled this with this line present in /var/ossec/etc/ossec.conf
<nodiff>/etc/letsencrypt/live/</nodiff>
<nodiff>/root/backups/*.key</nodiff>
  1. Not sure why it isn't working. Here's the files that were diff'd
    1. /etc/letsencrypt/live/openbuildinginstitute.org/cert.pem
    2. /etc/letsencrypt/live/opensourceecology.org/cert.pem
  2. I went ahead and added this to ossec.conf & gave ossec a restart *shrug*
<nodiff>cert.pem</nodiff>
  1. ...
  2. I also had an issue with phplist forbidden errors caused by this false-positive. I fixed it by whitelisting 960020 in /etc/httpd/conf.d/00-phplist.opensourceecology.org.conf & restarting apache
Message: Access denied with code 403 (phase 2). String match "HTTP/1.1" at REQUEST_PROTOCOL. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_20_protocol_violations.conf"] [line "399"] [id "960020"] [rev "2"] [msg "Pragma Header requires Cache-Control Header for HTTP/1.1 requests."] [severity "NOTICE"] [ver "OWASP_CRS/2.2.9"] [maturity "6"] [accuracy "8"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ"]             
Action: Intercepted (phase 2)
Stopwatch: 1581577253790393 8718 (- - -)
Stopwatch2: 1581577253790393 8718; combined=353, p1=324, p2=15, p3=0, p4=0, p5=14, sr=65, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache
Engine-Mode: "ENABLED"

Tue Feb 04, 2020

  1. sent Marcin an email saying that I will have limited time to contribute to OSE this year, and stated that I could commit to [a] finishing discourse, [b] training a replacement for me, and [c] serving only as an advisor for a few hours per month going forward after that

Sun Jan 26, 2020

  1. documentation, emails

Sat Jan 25, 2020

  1. Today I met with Satprem Maïni, director of the Auroville Earth Institute at their office in the CSR complex in Auroville, India. Marcin joined us via video call.
  2. A few notes about our meeting:
    1. Satprem was not familiar with OSE (but Richard--who I met earlier but was not present, was familiar with our wiki)
    2. We invited Satprem to join us for Summer_of_Extreme_Design-Build_2020
    3. Satprem showed me a document titled "Services Offered - 2020" which states that their consultancy fees are 450 EUR per person per day for less than a week and 350 EUR per person per day for more than a week. He said that this is negotiable for more than one week. Marcin asked for two weeks.
    4. We would also be responsible for paying for all expenses, including "flight in economy class, visa expenses, local transportation, boarding and lodging, laundry, food, water, etc"
    5. So I guess (if Satprem would be OK to stay at FeF), we'd be looking at roughly ~$7-$15k for this

...

  1. I asked Satprem about capillary action. He said if water gets into your CSEBs via capillary action, you have a design flaw. He stated that they've also built in very cold climates where it freezes
  2. I asked about the ~22m diameter CSEB dome they built. He said that they never waterproofed the roof, and it does leak. He said he hasn't visited it in a while, but last he checked they put coconut leaf roof over the dome--which is the traditional natural roof used here in Tamil Nadu
  3. Satprem also said that 2 weeks wouldn't be enough time to design & build a machine. We explained our swarm building approach.
  4. Marcin asked Satprem about his experience designing machines. He said that he doesn't have that skill, and that Aureka mostly designs their machines. I asked about Richard, and he said that it was still mostly an expertise possessed by Aureka. Marcin asked if Satprem would be interested in learning this, and Satprem said he has too much else to work on to focus on learning how to design machines.
  5. ...
  6. I asked Satprem about their open-source licensing of their machines. He said that they keep the designs for their AuroPress private within Auroville only. The auram press is made by Aureka.
  7. I asked Satprem about the books they've published, and he said that we could get the PDFs if we purchased them. He also gave us permission to publish the PDF on our wiki, including a spreadsheet that comes on a CD with one of the books.
  8. I told Satprem I would be happy to buy all of AVEI's books, but he suggested that I only buy three of them, so I bought these three:
    1. File:AVEI economic feasibility to set up a cseb unit.pdf
      1. this book includes a CD titled "Economics of CSEB" with a spreadsheet titled File:Intro 11 - CSEB Economics.xls
    2. File:AVEI building with arches vaults and domes.pdf
    3. File:AVEI production and use of compressed stabalized earth blocks.pdf

Mon Jan 20, 2020

  1. Emailed Satprem (AVEI director) asking his availability to meet with Marcin
Hi Satprem,

Would you be available to meet for an online video chat later this week
with our Director, Marcin Jakubowski?

My name is Michael. I am working with Open Source Ecology. We are
currently designing open-source blueprints for civilization. We also
work with Open Building Institute.

 * https://www.opensourceecology.org
 * https://www.openbuildinginstitute.org

One of the machines that we develop is an Earth Brick Press for making CEBs.

 * https://wiki.opensourceecology.org/wiki/CEB_Press

We'd like to invite you to visit us in the US in August. Would you be
available at any of the following times to discuss this further on an
internet video call?

 1. Thursday morning at 07:30 or 08:30 IST
 2. Friday morning after 10:30 IST
 3. Saturday morning at 07:30 or 08:30 IST

The meeting will be with Marcin Jakubowski (Director, Open Source
Ecology)--who will be joining remotely from the US--and myself. I'm
currently in Auroville, and I'd like to physically be present at the
AVEI office to meet you in person and to assist with any potential
technical difficulties.

Please let me know if any of these times work for you.


Thank you,

Michael Altfield
Senior System Administrator
PGP Fingerprint: 8A4B 0AF8 162F 3B6A 79B7  70D2 AA3E DF71 60E2 D97B

Open Source Ecology
www.opensourceecology.org

Sun Jan 19, 2020

  1. downloaded content for meeting with Satprem to phone

Sat Jan 18, 2019

  1. review of OSE CEB Press videos
  2. created table comparing OSE CEB Press to AVEI's

Fri Jan 17, 2019

  1. review of OSE CEB Press videos

Thr Jan 16, 2020

  1. email

Wed Jan 15, 2020

  1. uploading research & documentation on Auroville Earth Institute and their machines
  2. emails

Tue Jan 14, 2020

  1. OSE & AVEI brick press research

Mon Jan 13, 2020

  1. Researching OSE & AVEI brick presses
  2. Preparing notes for meeting with AVEI director https://wiki.opensourceecology.org/wiki/Visiting_Auroville_2020#Auroville_Earth_Institute

Sun Jan 12, 2020

  1. Documentation of the Auroville Earth Institute office & their Auroville Earth Institute (exhibition room).

Sat Jan 11, 2020

  1. Visited the Auroville Earth Institute office & their Auroville Earth Institute (exhibition room).

Thr Jan 02, 2020

  1. Marcin asked why www.opensourceecology.org takes 5 seconds to load and what we can do to speed it up
  2. I did some quick checking. There's a pretty absured number of assets requied to be downloaded to render our site. I did a quick search for "async" in the source code and couldn't find a single one. To fix this, here's my checklist TODO (but I doubt it's higher priority than Discourse; I asked for clairification from Marcin):
    1. Do a page load from a fresh session and watch the varnish logs for the client's IP. Verify that 100% of the assets requested on the front page are returned from the varnish cache. This essentially eliminates the fact that our server is running slow due to code, db calls, etc. This should be done first. We have tons of RAM, so if any assets are not there; we should modify the varnish config to make sure 100% of all front-page assets get cached by varnish.
    2. We should enumerate the assets from above and try disabling them in the browser one-by-one to see the effect. If any can be safely eliminated on all our sites, we should cut them out. This is not a trivial process, and it may be deferred until sufficient time to focus on this task is permitted.
    3. For remaining assets that are necessary, we'll want to minify and async them. We should research a very simple/fast/lightweight wordpress plugin that will do this for us in such a way that it itself creates a cache of the minified files so it's not wasting time doing the minification every time we have to make a call to the backend.
    4. We should research our CDN options. This should be taken seriously, as once we start using a CDN we could end-up injecting malicious content into our site that could be used to hack our users. Therefore, the CDN must be trustworthy so they won't be themselves malicious or neglegent enough to let themselves be unknowingly hacked by a malicous 3rd party.
    5. I sent an email to Fastly about their free CDN service for non-profits; more reasearch is needed though.
  3. Here's my email response
Without any investigation at all, I would ignorantly assume that this
may be caused by loading some large static asset dependencies, such as
javascript, css, images, etc that are blocking the content from arriving
to the browser.

If I'm correct, the solution is usually to:

 1. cut out unnecessary dependencies,
 2. "minify" any required dependencies (removes comments & whitespace
	and compresses them to decrease their size),
 3. make those resources "asynchronous/non-blocking" if possible (so
	they load *after* the page loads),
 4. cache them on the server side (varnish; may already be done, but
	validation would be necessary),
 5. tell browsers to cache them on the client side, and
 6. put any static assets we can on a super-fast CDN.

To determine if I'm correct, we can run the site through some online
load speed tools. They will usually load the site in a virtual browser,
enumerate the assets that were required, and show you the time required
to download the assets and render the page. I just did this with Google
Page Insights. Here's the results:

 *
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.opensourceecology.org

The above page suggests some of the resources blocking our page load
include twitter, bootstrap (probably required by the wordpress theme
we're using), and jquery. Our non-CDN images look pretty small & sane
as-is. And we may be able to remove some CSS files. Maybe.

The lowest hanging fruit is probably:

 1. Test enabling gzip compression encoding in apache (and maybe needed
	in vanish/nginx too)

And the next-lowest fruit is:

 1. Research CDN options. We may be eligible for free service as a
	non-profit.

I just emailed fastly, which a quick google suggested they provide free
CDN for non-profits. There's probably other options. And we should do
our research on this. We don't want a "free" CDN service that (either
intentionally or because they were hacked) does some sketchy injection
of malicious content into our site's resources. That's essentially how
thousands of e-commerce sites were hacked and had hundreds of thousands
of credit cards stolen in the Magecart web skimming scandal in 2018..

 * https://en.wikipedia.org/wiki/Web_skimming

The more direct but more time consuming solution is sifting through all
the shit that our theme is using and cutting out the unnecessary fat and
minifying the rest.

Please let me know the priority of this task compared to the Discourse POC.


Cheers,

Michael Altfield
Senior System Administrator
PGP Fingerprint: 8A4B 0AF8 162F 3B6A 79B7  70D2 AA3E DF71 60E2 D97B

Open Source Ecology
www.opensourceecology.org
Retrieved from "https://wiki.opensourceecology.org/index.php?title=Maltfield_Log/2020_Q1&oldid=212911"