~/virtual/home/joho | DeltaFelter | Stealth Cookie | FidoNet | Joaquim Homrighausen | joho68
Jitsi Meet is a wonderful open source video conferencing platform. Most things can be tweaked and configure to your needs.
If it’s important to you, that Jitsi Meet does not make external requests to third-party services like Gravatar, etc, you can change your xxx-config.js file in /etc/jitsi/meet like so:
disableThirdPartyRequests: true,
Credits: www.kuketz-blog.de/jitsi-meet-externe-verbindung-zu-gravatar-com/
I’ve been using the Mozilla Thunderbird e-mail client for … a long time. Google has had a “Less secure apps” policy, where you explicitly have to enable a setting to allow external access to things like e-mail over IMAP, and so on. Google has also been warning their users about upcoming changes, where clients that cannot authenticate using “secure methods” (such as OAuth2), will no longer be able to access things like e-mail over IMAP.
Fortunately (for me), Mozilla Thunderbird can handle this just fine 🙂
Incoming settings
Make sure you are using IMAP and not POP3. Go to your account settings. Go to server settings. You should see the IMAP settings (imap.gmail.com:993, etc). Make sure connection security is set to SSL/TLS. Set the authentication method to OAuth2 and re-start Thunderbird. You will be prompted with a Google Login Page. Enter your credentials for the account. Once Google has successfully verified the credentials, it will tell you that Thunderbird wants to access certain things. Allow this, and … you’re done. To verify that everything worked out as it should, re-start Thunderbird once more. You should not be getting any prompts this time.
Outgoing settings
To access settings for outbound e-mail using Gmail, click on the account name in the list to the left of the Account settings window. At the bottom, to the right, you will see Outoing Server (SMTP). Choose to Edit SMTP Server. Again, check your settings to be smtp.gmail.com (587), STARTTLS, and set the Authentication method to OAuth2, just like you did for IMAP. Re-start Thunderbird.
Repeat this procedure for all your Gmail accounts configured in Thunderbird.
The short version of this post: Wake the fuck up and smell the maple nut crunch!
The somewhat longer version follows.
The Netflix “documentary”, “The Great Hack”, is a great beginning of something that will take years to be argued, debated, and (mis)understood. Thinking that Cambridge Analytica is the “bad guy”, and “it’s going to be alright now that we know” is all too comfortable (and all too easy).
One serious issue with this and the people that are in charge of making sure it doesn’t happen is that they don’t understand, don’t want to understand, or are actually paid by people who have as their prime interest that they do not understand.
How the United Nations (UN) and other organizations cannot consider ownership of personal information to be a basic and fundamental human right is beyond me, but it also goes to show how slowly the “democratic” machinery works and how easily the system is manipulated by those who understand.
Getting clowns elected as “the ruler” of a nation, or deeply influencing referendums one way or the other, while sinister and non-democratic, is arguably, less dangerous than standing in the way of science in, perhaps, the most important question of our time; the climate debate.
When “data points” can be used to, in the best interest of fossil energy companies, manipulate people and nations to prevent science, common sense, and logic to have its way … we’re truly skating on thin ice; and, it’s melting.
Oh, and you seriously don’t think Google (and others) aren’t doing the same thing? Bwahahaha … that’s good comedy right there.
“War Pigs” and “The Dogs of War” (look them up) have more truth to them than we’d like to think.
The Great Hack (Netflix), IMDB:
www.imdb.com/title/tt9358204
The list of things to do to harden a WordPress site with Apache is long, but some things that could be done include:
FileETag None
<Files wp-config.php>
Require all denied
</Files>
<Files xmlrpc.php>
Require all denied
</Files>
<LocationMatch "/wp-content/uploads/.*(?i)\.php$">
Require all denied
</LocationMatch>
Because I have a lot of virtual machines, laptops, work environments, and so on, I never seem to find the time to setup SMTP authentication everywhere. I typically use Linux for everything except hardcore gaming, so it’s only natural that I have some sort of mail server installed like Postfix. The problem in using that mail server to send e-mail is that I also quite often have dynamic IP addresses on these machines, which doesn’t work well with “e-mail protection” (well..) like SPF.
So instead of making my life very complicated, I have a trusted server on the Internet through which I send e-mail.
If you were looking for something fancy in this article, you can move along now, there’s nothing to see 🙂
To make all my Linux work instances believe they’re talking to an SMTP server locally, I simply setup a tunnel from the given Linux instance to this trusted server on the Internet using the ever so versatile OpenSSH / SSH. I know there are a lot of ways to do this, but this is what works for me:
I have a private/public key keypair on all of these machines. The public key is placed in the /root/.ssh/authorized_keys file on the trusted server that is running the mail server.
On this machine, as root, I setup a tunnel that looks like this:
ssh -N -L 25:localhost:25 root@mail.example.org -p 2222
This will create a tunnel from “localhost” port 25 (where I work) to “localhost” port 25 on mail.example.org. It will connect the end point of the tunnel to mail.example.org on port 2222. If the mail.example.org server is running an SSH server on its standard port (22), you can remove the “-p 2222” part.
On this server, I only need to put the public key from the local machine “where I work” into /root/.ssh/authorized_keys to allow the tunnel to come up.
When I access port 25 on my local machine “where I work”, it will be sent through the tunnel and then attempt to access “localhost” port 25 on the mail server. The mail server software, Postfix in my case, will never know this connection did not actually originate from “inside” the machine, but rather through the tunnel.
You can (obviously) make this somewhat more automated with tools like AutoSSH, init scripts, and what not. The above only intends to show how uncomplicated it is to create useful SSH/SMTP tunnels 🙂
Overwriting “unused space” on Windows 7, Windows 8, and Windows 10 is quite simple. Open a “Command Prompt” window, and type:
cipher /w:DD
Where “DD” is your drive without a suffix, e.g.
cipher /w:C
to wipe unused space on drive C.
Why is this useful? Well, when you delete files from most modern operating systems, they aren’t really erased, even after you “Empty the trash”. The file system on your drive is simply updated to indicate that the space previously occupied by the file is now available. But the file data is still there. Overwriting such “unused space” with nonsense/garbage data will make it harder to recover the file data.
There’s another utility program from Microsoft called SDelete that has been around for quite some time. It goes about things slightly differently, but may do the job as well as cipher. You can find SDelete here.
I recently upgraded one of my laptops to Ubuntu 16.04.LTS (going from 14.04.LTS). The upgrade went very smooth and I have no issues with the resulting operating environment 🙂 Having said that, I quickly discovered a quite serious issue for me when I attempted connecting to one of many servers I need to get into. All of a sudden, my SSH key was no longer accepted by the server, and I was prompted for a password! WTF!?
I immediately feared the worst and started looking at the server(s), tailing log files, enabling debugging, etc. No trace was to be found other than that no key was presented by the client. The servers were intact, the authorized_keys had not been compromised, and vanilla ice cream was still the number one flavor. The problem is not with Ubuntu 16.04.LTS. The problem is with my SSH key, as well as a recent change in “acceptable keys” by OpenSSH, version 7.
Doing “ssh -vvv user@server.com” told me that the SSH client couldn’t find an acceptable key to present to the server. After having figured that out, and facepalming for a few seconds, I added this to my /etc/ssh/ssh_config file:
PubkeyAcceptedKeyTypes=+ssh-dss
Saved the file and tried again. Voila! One could say many things about using this type of SSH key, but rest assured I will change mine. You should too if you run into this problem. This is a workaround, not a fix or a solution. So sit down with some vanilla ice cream (with actual vanilla) and something nice to drink and go through the process of replacing your public SSH keys everywhere.