'Today we talk about Sogo. SOGo is a fully supported and trusted
groupware server with a focus on scalability and open standards, is
released under the GNU GPL/LGPL v2 and above. SOGo provides a rich
AJAX-based Web interface and supports multiple native clients through
the use of standard protocols such as CalDAV, CardDAV, and GroupDAV,
as well as Microsoft ActiveSync. In this tutorial we'll install on
Debian 8, a new version will be available soon.'
-- source: https://www.howtoforge.com/tutorial/how-to-install-sogo-on-debian-8/
Dept. of Computer Science
University of Waikato, NZ
+64 (7) 858-5174
The OpenVPN package on Debian comes with some systemd .service files to
make VPN connections easier to manage. These (all located
in /lib/systemd/system/) are named
Note the @-signs in the names of three of them: these indicate
“template” services, each of which can be “instantiated” any number of
times, to create multiple service “instances”.
There seem to be two alternative ways of defining your OpenVPN services
here: the first two .service files let you define and manage client-end
and server-end connections individually, and require you to start and
stop them separately, while the latter two don’t bother
distinguishing between client-end and server-end (this is purely up to
the respective OpenVPN configurations), they are all defined by
instantiating “openvpn@.service”. The non-template file,
“openvpn.service”, can then be used to start and stop all these
instances at once.
(It could be that the first two represent an older way of managing
connections, while the latter two are a newer, unified, more flexible
way. But hey...)
To illustrate how template instantiations work, I have been setting up
a VPN link between a virtual private server at Rimu Hosting and the
Internet router machine in my office. The VPS (with the fixed IP
address) is the server end, while my office end is the client.
On the server, I create a config file
named /etc/openvpn/server/office.conf that appropriately defines the
server end of the connection. The name “office” now automatically
becomes the name of the instance: to start this, I just type
systemctl start openvpn-server@office
and systemd automatically fills in the name “office” in place of the
“%i” placeholder in the contents of the openvpn-server@.service template
file, and executes the appropriate openvpn command. (One of the
occurrences of %i is in the name of the config file.)
At the client end, I create a config file
named /etc/openvpn/client/vps.conf that appropriately defines the client
end of the connection. Here the instance name is “vps”, so the systemd
command to launch openvpn at the client end is
systemctl start openvpn-client@vps
and as before, instances of “%i” in the template are replaced with the
instance name, “vps”. (As before, %i is also used to produce the name
of the config file.)
Of course, manually starting and stopping OpenVPN instances may be fine
for testing, but for production use you want this to happen
automatically at boot time. Just change the systemctl “start” commands
to “enable”, and it’s done.
Comparing current high-end CPU offerings from the two x86 vendors
it’s clear AMD has bounced back from many years in the “also-ran” back
row with its “Ryzen” and “Threadripper” offerings:
The difference is that AMD bet on a massively multicore future for
consumers and prosumers, designing an architecture with dramatic
scaling in mind, when Intel was still umming and ahhing whether to
bring six-core chips to the mainstream.
So if you make heavy use of multithreaded software, for example 3D
rendering, video encoding, or large software builds, then AMD currently
has a significant price/performance edge.
Interesting that one of the benchmarks is “Blenchmark”, which involves
using Blender to render a 3D BMW car model, while another builds
Google’s Chromium browser from source.
“Bulletproof” hosting providers tout their ability to stay online in
spite of the efforts of law enforcement to shut them down. Here is a
into some research detailing how they manage to keep operating:
One service cited by the work is a cloud proxy network that abuses
the services of legitimate providers including AWS and TenCent. The
product ... typically costs $250/month/domain and maintains
operations by cycling through an enormous number of providers – 230
in just nine days, according to the researchers.
Another provider ...is still in business despite being raided three
Operating out of political hotspots gives some BPH operations
another shield against takedown attempts.
The infamous Equifax breach (which has compromised the personal
information belonging to 140 million Americans) was down to a
vulnerability in an application library which had already been
discovered and a patch issued months before, but the patch was never
applied at the company.
Why does this sort of thing keep happening? Here is a research survey
being undertaken to try to better understand the real-world constraints
under which companies operate, with a view to making the software
update process more effective (i.e. more likely to be followed).
Bruce Schneier repeats a point that should be well-known about security
and Open Source, but which some still have trouble grasping:
This is one of the areas where open-source software has a security
edge. If everyone has access to the source code -- and security
doesn't depend on its secrecy -- then there's no advantage in
getting a copy. As long as companies rely on obscurity for their
security, these sorts of attacks are possible and profitable.
During the [Wall Street Journal]'s Tuesday test, searches for
hot-topic terms like "Las Vegas shooting" and "NFL anthem protest,"
along with the term "9/11," each brought up top-five video posts,
specifically listed in the site's "Top News" box, whose titles and
content were loaded with debunked and misleading content. The fifth
result for "Las Vegas shooting" was titled "Proof Las Vegas
Shooting Was a FALSE FLAG attack—Shooter on 4th Floor" and claimed
that multiple shooters had been involved, in spite of Vegas
officials stating otherwise.