From one of my customers, I received the request to figure out an installation pathway for ActivInspire, the Promethean smart board software suite. ActivInspire is offered as DEB builds for Ubuntu 18.04. On a Debian 10 (aka buster) system the installation requires some hack-around (utilizing packages from Debian jessie LTS).
Here is the quick-n-dirty recipe:
APT Key for "Promethean Ltd <support@prometheanworld.com>"
The APT key you need for downloading packages from Promethean's package archive can be obtained like this:
$ gpg --search-keys 0x300035F2484C6FED
$ gpg --export -a 0x300035F2484C6FED | sudo apt-key add -
Afterwards, you should find the key added to APT's GnuPG keyring. Verify that:
$ sudo apt-key adv --fingerprint D3CDA26CC37F568DD4A8DE68300035F2484C6FED
Executing: /tmp/user/0/apt-key-gpghome.HMo8gCMGUG/gpg.1.sh --fingerprint D3CDA26CC37F568DD4A8DE68300035F2484C6FED
pub rsa4096 2017-03-02 [SC]
D3CD A26C C37F 568D D4A8 DE68 3000 35F2 484C 6FED
uid [ unbekannt ] PrometheanLtd <support@prometheanworld.com>
sub rsa4096 2017-03-02 [E]
Tweak APT's Installation Sources
Next, add the below lines to a new file called /etc/apt/sources.list.d/promethean.list. The software will require to grab some packages (e.g.
Over the past weekend I attended "X2Go - The Gathering 2019". This year's venue was LinuxHotel in Essen. It was good to come back here.
Things that I got DONE while at the Gathering
X2Go related topics I worked on...
- Three informal talks about:
- the new/alternative X2Go Kdrive graphics backend for X2Go
- status report of my work on the X2Go Plugin for Remmina
- brain storming session: accessing X2Go sessions from a web browser
- Get Ubuntu Gnome Desktops (from 18.04 or later) working in X2Go (with X2Go Kdrive backend being used)
- Hide color manager authentication dialog on session startup of Gnome-based sessions in X2Go by nastily tweaking
colord's policy kit rule set
- Discuss various issues around nx-libs with Ulrich Sibiller and Mihai Moldovan
- Discuss Free Software and Civil Administration with Heinz-M. Graesing
- Discuss Free Software solutions for schools with Heinz-M.
"IServ Schulserver" [1] is a commercial school server developed by a company in Braunschweig, Germany. The "IServ Schulserver" is a product based on Debian. The whole project started as a students' project.
The "IServ" is an insular school server (one machine for everything + backup server) that provides a web portal / communication platform for the school (reachable from the internet), manages the school's MS Windows® clients via OPSI [2] and provides other features like chatrooms, mail accounts, etc.
The "IServ Schulserver" has written quite a success story in various areas of Germany, recently. IServ has been deployed at many many schools in Northrhein-Westfalia, Lower Saxony and Schleswig-Holstein. You can easily find those schools on the internet, if you search the web for "IServ IDesk".
The company that is developing "IServ" has various IT partner businesses all over Germany that deploy the IServ environment at local schools and are also the first point of contact for support.
It's all hear-say...
So, last night, I heard about a security design flaw not having been fixed / addressed since I had first heard about it. That was in 2014, when one of the Debian Edu schools I supported back then migrated over to IServ. At that time, the below could be confirmed. Last night, I learned that the following is still an issue on an IServ machine deployed recently here in Schleswig-Holstein (its deployment dates only a few weeks back). It's all hear-say, you know.
In August 2019, I have worked on the Debian LTS project for 24 hours (of 24.75 hours planned) and on the Debian ELTS project for another 2 hours (of 12 hours planned) as a paid contributor.
LTS Work
- Upload fusiondirectory 1.0.8.2-5+deb8u2 to jessie-security (1 CVE, DLA 1875-1 [1])
- Upload gosa 2.7.4+reloaded2+deb8u4 to jessie-security (1 CVE, DLA 1876-1 [2])
- Upload gosa 2.7.4+reloaded2+deb8u5 to jessie-security (1 CVE, DLA 1905-1 [3])
- Upload libav 6:11.12-1~deb8u8 to jessie-security (5 CVEs, DLA 1907-1 [4])
- Investigate on CVE-2019-13627 (libgcrypt20). Upstream patch applies, build succeeds, but some tests fail. More work required on this.
- Triage 14 packages with my LTS frontdesk hat on during the last week of August
- Do a second pair of eyes review on changes uploaded with dovecot 1:2.2.13-12~deb8u7
- File a merge request against security-tracker [5], add
--minor option to contact-maintainers script.
ELTS Work
- Investigate on CVE-2019-13627 (libgcrypt11). More work needed to assess if libgrypt11 in wheezy is affected by CVE-2019-13627.
References
Long time not blogged about, however, there is a new release of nx-libs: nx-libs 3.5.99.22.
What is nx-libs?
The nx-libs team maintains a software originally developed by NoMachine under the name nx-X11 (version 3) or shorter: NXv3. For years now, a small team of volunteers is continually improving, fixing and maintaining the code base (after some major and radical cleanups) of NXv3. NXv3 aka x2goagent has been the only graphical backend in X2Go [0], a remote desktop framework for Linux terminal servers, over the past years.
(Spoiler: in the near future, there will be two graphical backends for X2Go sessions, if you got curious... stay tuned...).
Credits
You may have noticed, that I skipped announcing several releases of nx-libs. All interim releases should have had their own announcements, indeed, as each of them deserved it. So I am sorry and I dearly apologize for not mentioning all the details of each individual release. I am sorry for not giving credits to the team of developers around me who do pretty hard work on keeping this beast intact.
The more, let me here here and now especially give credits to Ulrich Sibiller, Mihai Moldovan and Mario Trangoni for keeping the torch burning and for actually having achieved awesome results in each of the recent nx-libs releases over the past year or so. Thanks, folks!!!
Luckily, Mihai Moldovan (X2Go Release Manager) wrote regular release announcements for every version of nx-libs that he pulled over to the X2Go Git site and the X2Go upstream-DEBs archive site [1].
I recently uploaded libjpeg-turbo 2.0.2-1~exp1 to Debian experimental. This has been the first upload of the 2.0.x release series of libjpeg-turbo.
After 3 further upload iterations (~exp4 that is), the package now builds on nearly all (except 3) architectures supported by Debian.
@all: Please Test
For those architectures that libjpeg-turbo 2.0.2-1~exp* is already available in Debian experimental, please start testing your applications on Debian testing/unstable systems with libjpeg-turbo 2.0.2-1~exp* installed from experimental. If you observe any peculiarities, please file bugs against src:libjpeg-turbo on Debian BTS. Thanks!
Please note: the major 2.x release series does not introduce an SOVERSION bump, so applications don't have to be rebuilt against the newer libjpeg-turbo. Simply drop-in-replace installed libjpeg62-turbo bin:pkg by the version from Debian experimental.
[RFH] FTBFS during Unit Tests
On the alphas, powerpc and sparc64 architectures, the builds [1] fail during unit tests:
301/302 Test #155: tjunittest-static-yuv-alloc ....................... Passed 60.08 sec
302/302 Test #156: tjunittest-static-yuv-nopad .......................
I just migrated the first / a customer's mail server site away from Amavis+SpamAssassin to Rspamd. Main reasons for the migration were speed and the setup needed a polish up anyway. People on site had been complaining about too much SPAM for quite a while. Plus, it is always good to dive into something new. Mission accomplished.
Implemented functionalities:
- Sophos AV (savdi) antivirus checks backend
- Clam AV antivirus backend as fallback
- Auto-Learner CRON Job for SPAM mails published by https://artinvoice.hu
- Work-around lacking http proxy support
Unfortunately, I could not enable the full scope of Rspamd features, as that specific site I worked on is on a private network, behind a firewall, etc. Some features don't make sense there (e.g. greylisting) or are hard-disabled in Rspamd once it detects that the mail host is on some local network infrastructure (local as in RFC-1918, or the corresponding fd00:: RFC for IPv6 I currently can't remember).
Kudos + Thanks!
Rspamd is just awesome!!! I am really really pleased with the result (and so is the customer, I heard). Thanks to the upstream developers, thanks to the Debian maintainers of the rspamd Debian package. [1]
Credits + Thanks for sharing your Work
The main part of the work had already been documented in a blog post [2] by someome with the nick "zac" (no real name found).
Last week, I did a bundle upload of (nearly) all MATE 1.22 related components to Debian unstable. Packages should have been built by now for most of the 24 architectures supported by Debian (I just fixed an FTBFS of mate-settings-daemon on non-Linux host archs). The current/latest build status can be viewed on the DDPO page of the Debian+Ubuntu MATE Packaging Team [1].
Credits
Again a big thanks goes to the packaging team and also to the upstream maintainers of the MATE desktop environment. Martin Wimpress and I worked on most parts of the packaging for the 1.22 release series this time. On the upstream side, a big thanks goes to all developers, esp. Vlad Orlov and Wolfgang Ulbrich for fixing / reviewing many many issues / merge requests. Good work, folks!!! plus Big Thanks!!!
References
light+love,
Mike Gabriel (aka sunweaver)
In July 2019, I have worked on the Debian LTS project for 15.75 hours (of 18.5 hours planned) and on the Debian ELTS project for another 12 hours (as planned) as a paid contributor.
LTS Work
- Upload to jessie-security: libssh2 (DLA 1730-3) [1]
- Upload to jessie-security: libssh2 (DLA 1730-4) [2]
- Upload to jessie-security: glib2.0 (DLA 1866-1) [3]
- Upload to jessie-security: wpa (DLA 1867-1) [4]
The Debian Security package archive only has arch-any buildds attached, so source packages that build at least one arch-all bin:pkg must include the arch-all DEBs from a local build. So, ideally, we upload source + arch-all builds and leave the arch-any builds to the buildds. However, this seems to be problematic when doing the builds using sbuild. So, I spent a little time on...
- sbuild: Try to understand the mechanism of building arch-all + source package (i.e. omit arch-any uploads)... Unfortunately, there is no "-g" option (like in dpkg-buildpackage). Neither does the parameter combination ''--source --arch-all --no-arch-any'' result in a source + arch-all build. More investigation / communication with the developers of sbuild required here. To be continued...
In June 2019, I did not at all reach my goal of LTS/ELTS hours, unfortunately. (At this point, I could come up with a long story about our dog'ish family member and the infection diseases he got, the vet visits we did and the daily care and attention he needed, but I won't...).
I have worked on the Debian LTS project for 9,75 hours (of 17 hours planned) and on the Debian ELTS project just for 1 hour (of 12 hours planned) as a paid contributor.
LTS Work
- LTS: Setup physical box running Debian jessie (for qemu testing)
- LTS: Bug hunting mupdf regarding my CVE-2018-5686 patch backport
- LTS: Upload to jessie-security: mupdf (DLA-1838-1), 3 CVEs [1]
- LTS: Glib2.0: request CVE Id (CVE-2019-13012) + email communication with upstream [2]
(minor issue for Glib2.0 << 2.60)
- LTS: cfengine3: triage CVE-2019-9929, email communication with upstream (helping out security team) [3]
ELTS Work
- Upload to wheezy-lts: expat (ELA 136-1), 1 CVE [4]
References
|