diff options
Diffstat (limited to 'rss.xml')
| -rw-r--r-- | rss.xml | 497 |
1 files changed, 497 insertions, 0 deletions
@@ -16,6 +16,503 @@ <!-- LB --> <item> +<title>Server-Side Scripting with CGI</title> +<guid>https://landchad.net/cgi.html</guid> +<link>https://landchad.net/cgi.html</link> +<pubDate>Sun, 25 Jul 2021 14:29:44 -0400</pubDate> +<description><![CDATA[ + <header><h1>Server-Side Scripting with CGI</h1></header> + + <main> + <p> + The basic website tutorial here describes how to set up a static + website — one that just serves HTML files saved on your server, + and until you change something manually, the same content will be served + each time a given page is requested. This is perfectly enough for most + personal website needs. This is how blogs should be implemented, instead + of relying on bloatware like WordPress! + </p> + <p> + But sometimes you genuinely <i>do</i> need something more. You need your + website to serve different contents depending on the time, on who the + requester is, on the contents of a database, or maybe process user input + from a form. + </p> + <h2>CGI</h2> + <p> + CGI, or the Common Gateway Interface, is a specification to allow you, + the server owner, to program your web server using pretty much any + programming language you might know. The specification is almost as old + as the Internet itself and for a long time CGI scripting was the primary + method of creating dynamic websites. + </p> + <p> + CGI is a very simple specification indeed. You write a script in your + favorite language, the script receives input about the request in + environment variables, and whatever you print to the standard output + will be the response. Most likely, though, you will want to use a + library for your language of choice that makes a lot of this + request/response handling simpler (e.g. parsing query parameters for + you, setting appropriate headers, etc.). + </p> + <h3>Limitations of CGI</h3> + <p> + While in theory you could implement any sort of functionality with CGI + scripts, it's going to get difficult managing a lot of separate scripts + if they're supposed to be working in tandem to implement a dynamic + website. If you want to build a full out web application, you'd probably + be better off learning a web framework than gluing together Perl + scripts. + </p> + <p> + That said, just as most of the web could be replaced with static + websites, much of the remaining non-static web could be replaced with a + few simple scripts, rather than bloated Ruby on Rails or Django + applications. + </p> + <h2>Let's write a CGI script!</h2> + <p> + We'll implement a simple example CGI script. I'll use Ruby for this + tutorial, but you'll be able to follow along even if you don't know + Ruby, just treat it as pseudocode then find a CGI library for your + language. + </p> + <h3>The working example</h3> + <p> + Our working example will be the Lazy Calculator. Yeah, you're probably + tired of seeing calculator examples in every programming tutorial, but + have you ever implemented one that takes the weekends off? + </p> + <p> + Here's how it will work. When in a browser you submit a request to your + website like + </p> + <pre><code>example.com/calculator.html?a=10&b=32</code></pre> + <p> + you will receive a page with the result of the addition of 10 and 32: + 42. + </p> + <p> + <i>Unless</i> you send your request on a weekend. Then the website will + respond with + </p> + <pre><code>I don't get paid to work on weekends! Come back Monday.</code></pre> + <p> + This example will show a few things that CGI scripts can do that you + wouldn't have been able to get using just file hosting in your + web server: + <ul> + <li> getting inputs from the user; </li> + <li> + getting external information (here just the system time, but you + could imagine instead connecting to a database); + </li> + <li> using the above to create dynamic output. </li> + </ul> + <h3>The code</h3> + <p> + Here's an implementation of the lazy calculator as a Ruby CGI script: + </p> + <pre><code>#!/bin/env ruby +require 'cgi' +require 'date' +cgi = CGI.new +today = Date::today +a = cgi["a"].to_i +b = cgi["b"].to_i +if today.saturday? || today.sunday? + cgi.out do + "I don't get paid to work on weekends! Come back Monday." + end +else + cgi.out do + (a + b).to_s + end +end</code></pre> + <p> + Let's go through what's happening here. + </p> + <h3>The shebang line</h3> + <p> + CGI works by pointing your web server to an executable program. A Ruby + or Python script by itself is not immediately executable by a computer. + But on Unix-like systems you can specify the program that will be able + to execute your file in its first line if it starts with <code>#!</code> + (known as the shebang; read more about it on + <a href="https://en.wikipedia.org/wiki/Shebang_(Unix)">Wikipedia</a>). + </p> + <p> + So if you're going to be using a scripting language, you'll probably + need the appropriate shebang line at the top of your script. If you use + a compiled language, you'll just point your web server to the compiled + executable binary. + </p> + <h3>Query parameters</h3> + <p> + The next interesting lines of code are where we set the variables + <code>a</code> and <code>b</code>. Here we are getting user inputs from + the request. + </p> + <p> + In the example request we mentioned above + (<code>example.com/calculator.html?a=10&b=32</code>), the part + starting from the question mark, <code>?a=10&b=32</code>, is the + <i>query string</i>. This is how users can submit parameters with their + web requests. Usually these parameters are set by e.g. a form on your + website, but in our simple example we'll be just manually manipulating + the URL. + </p> + <p> + The query string contains key-value pairs. The Ruby CGI library makes + them available in the <code>CGI</code> object it provides. We just need + to index it with the desired key, and we'll get the corresponding value. + </p> + <h3>Wrapping it up</h3> + <p> + The remaining parts of the code should be pretty self-explanatory. We + get today's date, check if it's a Saturday or a Sunday, and depending on + that, we instruct the CGI library to output either the answer, or a + "come back later" message. + </p> + <p> + The Ruby library by default returns an HTML response, so we really + should have wrapped our outputs in some <code>html</code>, + <code>body</code>, etc. tags. Alternatively, we could have specified + that the response is just plain text with + </p> + <pre><code>cgi.out 'text/plain' do</code></pre> + <p> + In general, your CGI library will probably have ways of specifying all + sorts of HTTP response headers, like status code, content type, etc. + </p> + <h2>Making it work</h2> + <p> + We have a CGI script, now let's point our web server to it. + </p> + <h3>Installing FastCGI</h3> + <p> + If you're using Nginx, install <code>fcgiwrap</code>: + </p> + <pre><code>apt install fcgiwrap</code></pre> + <p> + This installs the necessary packages for Nginx to use FastCGI — a + layer between your web server and CGI script that allows for faster + handling of scripts than if the web server had to handle it all by + itself. + </p> + <p> + Other web servers will probably have a similarly simple way of enabling + FastCGI, or you can look into other methods for launching CGI scripts. + </p> + <h3>Nginx configuration</h3> + <p> + In the configuration file for your website, add something like the + following: + </p> +<pre><code>location /calculator.html { + include fastcgi_params; + fastcgi_param SCRIPT_FILENAME /usr/local/bin/lazy-calculator.rb; + fastcgi_param QUERY_STRING $query_string; + fastcgi_pass unix:/run/fcgiwrap.socket; +}</code></pre> + <p> + <code>fastcgi_param</code> directives specify various parameters for + FastCGI. <code>SCRIPT_FILENAME</code> should point to your executable. + For <code>QUERY_STRING</code>, we just copy Nginx's + <code>$query_string</code> variable. You might want to pass other + information to your CGI script as well, see for example + <a href="https://wiki.debian.org/nginx/FastCGI">the Debian wiki</a> for + a more detailed example, including pointing to an entire directory of + CGI scripts, rather than adding each one by hand to your web server + config. + </p> + <h2>Contribution</h2> + <ul> + <li>Martin Chrzanowski -- <a + href="https://m-chrzan.xyz">website</a>, <a href="https://m-chrzan.xyz/crypto.html">donate</a></li> + </ul> + </main> + +]]></description> +</item> + + +<item> +<title>XMPP Server (Prosody)</title> +<guid>https://landchad.net/xmpp.html</guid> +<link>https://landchad.net/xmpp.html</link> +<pubDate>Wed, 21 Jul 2021 22:58:21 -0400</pubDate> +<description><![CDATA[ + <header><h1>XMPP Server (Prosody)</h1></header> + + <main> + <img class=titleimg src="pix/xmpp.svg" alt="XMPP Logo and Icon"> + <p>XMPP is a fantastically simple protocol that's usually used as a messenger. + It's highly extensible, + better than IRC, + lighter and more decentralized and Matrix + and Telegram and normie social media can't hold a candle to it. + </p> + <p> + XMPP is so decentralized and extensible that there are many <em>different</em> XMPP servers. + Here, let's set up an <a href="https://prosody.im/">Prosody</a> XMPP server. + </p> + <h2>Installation</h2> + <p> + Prosody is in the Debian repositories, so we can easily install it on our server with the following command: + </p> + <pre><code>apt install prosody</code></pre> +<h2>Configuration</h2> +<p> +The Prosody configuration file is in <code>/etc/prosody/prosody.cfg.lua</code>. +To set it all up, we will be changing several things. +</p> +<h3>Setting Admins</h3> +<p> +Let's go ahead and set who our admin(s) will be. +Find the line that says <code>admins = { }</code> and to this we can specify one or more server admins. +</p> +<pre><code># To add one admin: +admins = { "chad@example.org" } +# We can add more than one by separating them by commas. (This file is written in Lua.) +admins = { "chad@example.org", "chadmin@example.org" }</code></pre> +<p> +Note that we have not created these accounts yet, we will do this <a href=#user>below</a>. +</p> +<h3>Set the Server URL</h3> +<p> +Find the line <code>VirtualHost "localhost"</code> and replace <code>localhost</code> with your domain. +In our case, we will have <code>VirtualHost "example.org"</code> +</p> +<h3>Multi-User Chats</h3> +<p> +Most people will probably want the ability to have chats with more than two users. +This is easily enough to enable. +In the config file, add the following: +</p> +<pre><code>Component "<strong>chat.example.org</strong>" "muc" + modules_enabled = { "muc_mam" } + restrict_room_creation = "admin"</code></pre> +<p> +On the first line, you must have a separate subdomain for your multi-user chats. +I use the <code>chat.</code> subdomain, but some use <code>muc.</code>. +Anything if possible. +</p> +<p> +The second line is important because it prevents non-admins from creating and squatting rooms on your server. +The only situation where you might not want that is if you indend to open a general public chat system for people you don't know. +</p> +<aside> +<p> +Read more about the <code>muc</code> plugin on the Prosody documentation page <a href="https://prosody.im/doc/modules/mod_muc">here</a>. +</p> +</aside> +<h3>End-to-end Encryption</h3> +<p> +Importantly, we'll want end-to-end encryption enabled for user privacy. +</p> +<p> +Find the array beginning with <code>modules_enabled</code>. +This includes a list of modules to be used. +Add +<code>"omemo_all_access";</code> to that list. +Additionally, be sure to change the module <code>pep</code> to <code>pep_simple</code> or this will cause a conflict.</p> +<p> +This module is not installed by default, +but you can easily download it by running the following command on the command prompt +to download and install the module to the correct directory. +</p> +<pre class=wide><code>curl -sL https://hg.prosody.im/prosody-modules/raw-file/785389a2d2b3/mod_omemo_all_access/mod_omemo_all_access.lua > /usr/lib/prosody/modules/mod_omemo_all_access.lua</code></pre> +<h3>Other things to check</h3> +<p>Check the config file for other settings you might want to change. +For example, if you want to run a general public XMPP server, you can allow anyone to create an account by changing <code>allow_registration</code> to <code>true</code>. +</p> +<h2>Certificates</h2> +<p> +Obviously, we want to have client-to-server and server-to-server encryption. +Nowadays, use can use Certbot to generate certificates and use a convenient command below <code>prosodyctl</code> to import them. +</p> +<p> +<strong>If you have multi-user chat enabled, be sure to get a certificate for that subdomain as well.</strong> +Include the <code>--nginx</code> option assuming you have an Nginx server running. +</p> +<pre><code>certbot -d <strong>chat.example.org</strong> --nginx</code></pre> +<p> +Once you have the certificates for encryption, run the following to import them into Prosody. +</p> +<pre><code>prosodyctl --root cert import /etc/letsencrypt/live/</code></pre> +<p> +Note that you might get an error that a certificate has not been found if your <code>muc</code> subdomain and your main domain share a certificate. +It should still work, this is just notifying you that no specific +</p> +<p> +For user privacy, we will definitely want to install and enable encryption with OMEMO. +</p> +<h2 id=user>Creating users/admins manually</h2> +<p> +Let's manually create the admin user we prepared for above. +Note that you can indeed do this in your XMPP client if you have not disabled registration, but this is how it is done on the command line: +</p> +<pre><code>prosodyctl adduser <strong>chad@example.org</strong></code></pre> +<p>This will prompt you to create a password as well.</p> +<h2>Make changes active</h2> +<p> +With any system service, use <code>systemctl reload</code> or <code>systemctl restart</code> to make the new settings active: +</p> +<pre><code>systemctl restart prosody</code></pre> +<h2>Using your Server!</h2> +<p> +Once your server is set up, you just need an XMPP client to use your new and secure chat system. +</p> +<ul> + <li>GNU/Linux: <a href="https://dino.im/">Dino</a> or <a href="https://gajim.org/">Gajim</a></li> + <li>Windows: <a href="https://gajim.org/">Gajim</a> also runs on Windows.</li> + <li>Android: <a href="https://conversations.im/">Conversations.im</a></li> + <li>Mac/iOS: <a href="https://monal.im/">Monal IM</a> or <a href="https://siskin.im/">Siskin</a> for iOS alone</li> + <li>command-line (GNU/Linux, MacOS, Windows): <a href="https://profanity-im.github.io/">Profanity</a></li> + <li><a href="https://xmpp.org/software/clients.html">See a more complete list kept by XMPP</a></li> +</ul> +<p> +Install whichever of these clients you want on your computer or phone and you can log into your new XMPP server with the account you made. +Note that if you enabled public registration, anyone can create an account on your server through one of these clients. +</p> +<h3>Account addresses</h3> +<p> +XMPP account addressed look just like email addresses: <code><strong>username@example.org</strong></code>. +You can message any account on any XMPP server on the internet with that format. +</p> +<h3>Note on MUCs (multi-user chats)</h3> +<p> +Remember that MUCs are kept on a separate subdomain that we created and should've gotten a certificate for above, for example, <code><strong>muc.example.org</strong></code>. +Chatrooms are created and referred to in the following format: <code><strong>#chatroomname@muc.example.org</strong></code>. +</p> + </main> + +]]></description> +</item> + + +<item> +<title>Setting up RSS Bridge</title> +<guid>https://landchad.net/rss-bridge.html</guid> +<link>https://landchad.net/rss-bridge.html</link> +<pubDate>Mon, 05 Jul 2021 18:11:15 -0400</pubDate> +<description><![CDATA[ + <header><h1>Setting up RSS Bridge</h1></header> + + <main> + <p>RSS Bridge is a useful utility you can use to help you avoid the big tech sites, like Facebook and Twitter, which instead of the feed you usually would see, will be a based and minimalist RSS feed. </p> + <p>You'll need a server or VPS. Nearly any Operating system is supported but for this tutorial I'm gonna presume you're using a Debian-based OS. You'll also need a domain name pointing to your server's IP address <a href="https://landchad.net/dns.html">which is explained in this tutorial.</a> + </p> +<h2>Installation</h2> +<h3>Setting Up and Configuring</h3> +<p>First things first you'll need to make sure that you've hardened you SSH so that password authentication is disabled and you'll also want to setup Fail2Ban. +There's a great tutorial on how to do this <a href="https://landchad.net/sshkeys.html">which can be read here.</a> +</p> +<p> +Next we'll install the required packages: +</p> +<pre><code>apt install -y curl unzip nginx certbot php-fpm php-mysql php-cli php7.3-mbstring php7.3-curl php7.3-xml php7.3-sqlite3 php7.3-json</code></pre> +<p>We now have to create the website configuration file. Create/open the a file below:</p> +<pre><code>nano /etc/nginx/sites-available/rss-bridge</code></pre> +<p>And add the following content:</p> +<pre><code>server { + root /var/www/rss-bridge; + index index.php index.html index.htm index.nginx-debian.html; + server_name rss-bridge.<strong>example.org</strong>; + location / { + try_files $uri $uri/ =404; + } + location ~ \.php$ { + include snippets/fastcgi-php.conf; + fastcgi_pass unix:/var/run/php/php7.3-fpm.sock; + } + location ~ /\.ht { + deny all; + } +} +</code></pre> +<p>After you have saved the file, you need to create a symlink so the server actually will read the file.</p> +<pre><code>ln -s /etc/nginx/sites-available/rss-bridge /etc/nginx/sites-enabled/rss-bridge</code></pre> +<p>Then we have to create the folder where the service will reside in.</p> +<pre><code>mkdir -p /var/www/rss-bridge +cd /var/www/rss-bridge +</code></pre> +<p>Lets download the latest version of RSS-Bridge in the directory.</p> +<p>The newest version can be found <a href="https://github.com/RSS-Bridge/rss-bridge/releases">here</a>, at the time of writing that is "RSS-Bridge 2021-04-25."</p> + <pre><code>wget https://github.com/RSS-Bridge/rss-bridge/archive/refs/tags/<strong>2021-04-25.zip</strong></code></pre> +<p>Unzip the file:</p> +<pre><code>unzip <strong>2021-04-25.zip</strong></code></pre> +<p>This will create a directory called rss-bridge-version-number, we now want to move all the file contents of the newly created directory to the one we are in</p> +<pre><code>mv <strong>rss-bridge-2021-04-25</strong>/* . +rm -rf <strong>rss-bridge-2021-04-25 2021-04-25.zip</strong> +</code></pre> +<p>Now all we need to do is grant read/write permissions and reload the web server.</p> +<pre><code>chown -R www-data:www-data /var/www/rss-bridge +systemctl reload nginx +</code></pre> +<p>That's it, you should now have a working rss-bridge installed. But you should definately get an SSL certifcate installed <a href="https://landchad.net/certbot.html">which is done briefly here</a>.</p> +<ul> + <li><a href="https://handskemager.xyz">handskemager.xyz</a></li> + <li>Bitcoin: <code class=crypto>bc1qhfjgwjzksf2auqjefwpvq20wvyugq3lhqgkxvu</code></li> + <li>Monero: <code class=crypto>88cPx6Gzv5RWRRJLstUt6hACF1BRKPp1RMka1ukyu2iuHT7iqzkNfMogYq3YdDAC8AAYRqmqQMkCgBXiwdD5Dvqw3LsPGLU</code></li> +</ul> + </main> + +]]></description> +</item> + + +<item> +<title>Rsync: Upload and Sync Files and Websites</title> +<guid>https://landchad.net/rsync.html</guid> +<link>https://landchad.net/rsync.html</link> +<pubDate>Sat, 03 Jul 2021 08:58:29 -0400</pubDate> +<description><![CDATA[ +<header><h1>Rsync: Upload and Sync Files and Websites</h1></header> +<main> + <p>rsync is a simple way to copy files and folders between your local computer and server.</p> + <p>It not only makes file-transfer easy, but it allows you to build and maintain your website offline, then easily upload it to the proper directory on your server so you don't need to constantly be logged into your server to modify your site.</p> +<h2 id="installing-rsync">Installing rsync</h2> +<p>Run the following on your server <em>and</em> on your local machine.</p> +<pre><code>apt install rsync</code></pre> +<h2 id="uploading-files-with-rsync">Uploading files with rsync</h2> +<p>From your local machine you can upload files to your server like this:</p> +<pre><code>rsync -ruvzP <strong>/path/to/file</strong> <strong>root@example.org:/path/on/the/server</strong></code></pre> +<p>You will be prompted for the root password and then uploading will commence.</p> +<p>If you omit <strong>root@</strong>, rsync will not attempt to log in as root, but whatever your local username is.</p> +<h3>Options to rsync</h3> +<p>In this command, we give several options to rsync:</p> +<ul> + <li><code>-r</code> – run recurssively (include directories)</li> + <li><code>-u</code> – update files (do not reupload files that are not changed since last upload)</li> + <li><code>-v</code> – visual, show files uploaded</li> + <li><code>-z</code> – compress files for upload</li> + <li><code>-P</code> – if uploading a large file and upload breaks, pick up where we left off rather than reuploading the entire file</li> +</ul> +<p>Avoid using the commonly used <code>-a</code> option when uploading. It changes can transfer your local machine's user and group permissions to your server, which might cause breakage.</p> +<h3>Scriptability</h3> +<p>It's a good idea to build your website offline, then make an rsync script or bash alias like the one above to upload the edited files when you have made updates.</p> +<h3>Password-less authentication</h3> +<p>To avoid having to manually input your password each upload, you can set up <a href="sshkeys.html">SSH keys</a> to securely idenitify yourself and computer as a trusted.</p> +<h3>Picky trailing slashes</h3> +<p>rsync is very particular about trailing slashes. This is useful, but can be confusing to some new users. Suppose we run the following wanting to mirror our offline copy of our website in the directory we use on our server (<code>/var/www/websitefiles/</code>):</p> +<pre><code>rsync -ruvzP ~/<strong>websitefiles/</strong> root@example.org:/var/www/<strong>websitefiles/</strong></code></pre> +<p>This will <em>not actually do quite what we want</em>. It will take our local <code>websitefiles</code> directory and put it <em>inside</em> <code>websitefiles</code> on the remote machine, ending up with: <code>/var/www/websitefiles/websitefiles</code>.</p> +<p>Instead, remove the trailing slash from the remote server location:</p> +<pre><code>rsync -ruvzP ~/<strong>websitefiles/</strong> root@example.org:/var/www/<strong>websitefiles</strong></code></pre> +<p><code>websitefiles/</code> has been replaced with <code>websitefiles</code>, and this will do what we want.</p> +<h2 id="downloading-file-with-rsync">Downloading files with rsync</h2> +<p>You may just as easily download files and directories from your server with rsync:</p> +<pre><code>rsync -urvzP <strong>root@example.org:/path/to/file</strong> <strong>/path/to/file</strong></code></pre> +<h2 id="contribution">Contribution</h2> +<ul><li>el3ctr0lyte: <a href="https://github.com/el3ctr0lyte">github</a>, XMR: <code class=crypto>86DBJdiG83ZDea6kJgsbVN5tMae5ScfuhJ3PihEMTHatCrGEw2gctyUB92V2fz4R4YhwRaQeAGL5M4gPRXvVvtkULJi4ayk</code></li><li>Substantial revisions by <a href="https://lukesmith.xyz">Luke</a></li></ul> +</main> +]]></description> +</item> + + +<item> <title>Setup a Pleroma Server</title> <guid>https://landchad.net/pleroma.html</guid> <link>https://landchad.net/pleroma.html</link> |