[DONE] pepperflash-plugin-adobe-nonfree

hhh · 2016-07-23 21:10:30

EDIT, by Johnraff: This thread has been split off from the "flash in bl-welcome" topic, of which this is a sub-issue. ( https://forums.bunsenlabs.org/viewtopic.php?id=2414 )

The script, and debian package, referred to here is for downloading the 32bit Flash browser plugin directly from Adobe. It does essentially the same job as pepperflash-plugin-nonfree does for 64bit systems, but with a systemd timer added for daily automatic update checks.

The latest debian package is linked below: https://forums.bunsenlabs.org/viewtopic … 841#p37841

Related earlier discussion here: https://forums.bunsenlabs.org/viewtopic.php?id=1873

--------------

johnraff wrote:

I have posted a script to automate the download/install here, but bear in mind that no checksum testing is done on the downloaded file.

This is bloody brilliant.

Steps summary (tested on 32 bit jessie)...

Enable Debian jessie-backports in your sources, make sure contrib is included and apt update.
Install browser-plugin-freshplayer-pepperflash (and chromium).
Create a file foo.sh and copy John's script to it, make the file executable.
Run ./foo.sh in a terminal.

Questions; Will an outdated plugin block content with a warning in chromium? How do I update, just run the script again?

Note; for 32 bit, I copied manifest.json from the Adobe tar.gz to /opt/google/chrome/PepperFlash (created the folder) to stop a grep 'no such file/folder' message that 32 bit chromium was producing, not related to the script.

Last edited by johnraff (2016-10-24 06:05:01)

johnraff · 2016-07-24 08:34:13

hhh wrote:

Run ./foo.sh in a terminal.

The script takes options. If you run it with no arguments (or --help) it should show a help message.

1) Will an outdated plugin block content with a warning in chromium? 2) How do I update, just run the script again?

1) The script should exit if pepperflashplugin-nonfree is still installed, so there should be no outdated plugins around. 2) See the help message!

Note; for 32 bit, I copied manifest.json from the Adobe tar.gz to /opt/google/chrome/PepperFlash (created the folder) to stop a grep 'no such file/folder' message that 32 bit chromium was producing, not related to the script.

This script is only for 32 bit. I saw no such messsage at any point with Chromium.

hhh · 2016-07-24 15:58:04

johnraff wrote:

This script is only for 32 bit. I saw no such message at any point with Chromium.

It was present when logging in to a virtual console, something like...

grep /opt/google/chrome*/PepperFlash/manifest.json No such file or directory
You have new mail.

Your script ran without warnings or errors. Debian doesn't include a manifest.json file anywhere that I can see...
https://packages.debian.org/jessie/amd6 … e/filelist
https://packages.debian.org/jessie-back … h/filelist
https://packages.debian.org/jessie-back … h/filelist
https://packages.debian.org/jessie/amd6 … m/filelist
https://packages.debian.org/jessie/i386 … m/filelist

I'll keep an eye out for this on my next tests, but this is just a warning about a 'missing' file.

johnraff · 2016-07-25 03:30:50

The manifest.json is packaged along with libpepflashplayer.so, both in Adobe's .tar.gz and in Google-chrome somewhere. Since that (unfree) stuff is downloaded after installing the package, it won't appear in any Debian file lists.

I wonder what script is running that grep on it? It might be something to do with browser-plugin-freshplayer-pepperflash because I just read this morning in that package's README

It's better to have `manifest.json` alongside with `libpepflashplayer.so`, actual Flash version will be taken from that manifest.

Maybe the package is checking that directory for a .json file? I suppose you'd have to start up Firefox to trigger that.
I don't know why it thinks the file should be in /opt/google/chrome*/PepperFlash/ though. Have you got a different libpepflashplayer.so there? My script puts it in /usr/lib/PepperFlash

Anyway I should modify the script to copy in the json file along with libpepflashplayer.so I guess.

Last edited by johnraff (2016-07-25 03:34:14)

hhh · 2016-07-25 08:49:49

^ Not yet, please. I should confirm my own report before you do anything.

johnraff · 2016-07-29 06:03:49

OK leaving it for now.
It could probably use some other improvements too, but to me the big IF standing in the way of its path to fame and fortune is the fact that it doesn't do any checksum testing on the downloaded .tar.gz file. Adobe don't seem to publish them anywhere. (Of course the same applies to manual downloads/installs.) Considering what an unsafe install it is anyway, how much more unsafe does that make it? Anyone?

Horizon_Brave · 2016-07-29 07:09:06

johnraff wrote:

OK leaving it for now.
It could probably use some other improvements too, but to me the big IF standing in the way of its path to fame and fortune is the fact that it doesn't do any checksum testing on the downloaded .tar.gz file. Adobe don't seem to publish them anywhere. (Of course the same applies to manual downloads/installs.) Considering what an unsafe install it is anyway, how much more unsafe does that make it? Anyone?

Well... I hate to sound like the guy in the movies who says "What can possibly go wrong?" Before the alien or monster kills them. But considering you're volunteeringly wanting Flash, and the fact that Flash itself in the browser is a very well known surface of attack for security holes, even when the correct, legit copy is downloaded, I'd say that the checksumming is sort of the least of the evils. Also isn't it possible to provide a checksum on bunsenlabs.org?

johnraff · 2016-07-29 07:25:23

Horizon_Brave wrote:

considering you're volunteeringly wanting Flash, and the fact that Flash itself in the browser is a very well known surface of attack for security holes, even when the correct, legit copy is downloaded, I'd say that the checksumming is sort of the least of the evils.

That's what I was thinking too.

Also isn't it possible to provide a checksum on bunsenlabs.org?

It would be possible - that's what the Debian packages flashplugin-nonfree and pepperflashplugin-nonfree do. The catch is that the checksum has to be updated every time the Adobe plugin changes. It's extra work and the possible cause of more update glitches.

Horizon_Brave · 2016-07-29 07:47:23

johnraff wrote:

Horizon_Brave wrote:
considering you're volunteeringly wanting Flash, and the fact that Flash itself in the browser is a very well known surface of attack for security holes, even when the correct, legit copy is downloaded, I'd say that the checksumming is sort of the least of the evils.
That's what I was thinking too.
Also isn't it possible to provide a checksum on bunsenlabs.org?
It would be possible - that's what the Debian packages flashplugin-nonfree and pepperflashplugin-nonfree do. The catch is that the checksum has to be updated every time the Adobe plugin changes. It's extra work and the possible cause of more update glitches.

I haven't kept track of the timeline of Adobe updates, but considering official Adoble support for linux is probably on life support anyway, how often would they realistically update this? Would it be on par with the amount of updates for regular Windows Flash? or even linux 64bit flash?

johnraff · 2016-07-29 08:53:09

Both the old NPAPI and newer PPAPI plugins get updated fairly regularly in fact. NPAPI is due to be dropped (next year?) but PPAPI should be around for a while. Whether they decide to drop the 32bit version of PPAPI some day is another question, but as long as it's available it gets updated in sync with 64bit.

johnraff · 2016-08-13 02:30:40

hhh wrote:

^ Not yet, please. I should confirm my own report before you do anything.

@hhh I know you're really busy just now. Is it OK if I go ahead and try to improve the script a little?

johnraff · 2016-08-16 08:02:39

Anyway, I've put an improved version of the script here:
https://forums.bunsenlabs.org/viewtopic … 073#p35073

The former version is still intact a couple of posts above.

If anyone feels like taking the new script for a spin (32bit systems only) any reports will be most appreciated.

johnraff · 2016-08-18 07:27:21

In fact, rather than that, if anyone has the time to install this deb file on a i386 virtual or real machine and check if it enables flash on Chromium (and Firefox too with browser-plugin-freshplayer-pepperflash), any feedback will be much appreciated!
https://dl.dropboxusercontent.com/u/108 … 1_i386.deb

If it works OK (it worked on my i386 VB) it will be very easy to install it from bl-welcome, and simple for the user to uninstall flash afterwards too -just remove the package.

...That's if Sherrif Two-irons is OK with having something like this in the BL (backports?) repos.

Last edited by johnraff (2016-08-18 07:29:06)

Head_on_a_Stick · 2016-08-18 20:46:32

johnraff wrote:

if anyone has the time to install this deb file on a i386 virtual or real machine and check if it enables flash on Chromium (and Firefox too with browser-plugin-freshplayer-pepperflash), any feedback will be much appreciated!

Works for me with a fresh 32-bit install:

johnraff · 2016-08-19 07:32:40

^Thanks!

I'm thinking maybe to get it to also add a cron job for regular update checks.

Head_on_a_Stick · 2016-08-19 07:34:44

johnraff wrote:

add a cron job for regular update checks.

I would recommend a systemd timer unit as that would work on both laptops and desktops.

Give me a minute and I'll write one...

EDIT:

# /etc/systemd/system/flash.timer

[Unit]
Description=Update flash daily

[Timer]
OnCalendar=daily
Persistent=true     
 
[Install]
WantedBy=timers.target

# /etc/systemd/system/flash.service

[Unit]
Description=Update flash

[Service]
Type=simple
ExecStart=/path/to/update/script

Enable the timer with:

# systemctl enable flash.timer

This is preferable to ana/cron jobs as it integrates with `journalctl` and allows the user to easily check if the package is being updated.

Last edited by Head_on_a_Stick (2016-08-19 07:42:37)

johnraff · 2016-08-21 03:16:39

^@HoaS thank you for that! I missed it because it was an edit, so I got no notification.

New version: https://dl.dropboxusercontent.com/u/108 … 1_i386.deb

Fixes an error when installing with the flash plugin already present, but doesn't yet incorporate the systemd timer.

I've put the source on my personal GitHub repo for the time being: https://github.com/johnraff/pepperflash … be-nonfree

Last edited by johnraff (2016-08-21 03:22:14)

johnraff · 2016-09-02 08:44:08

Belated thanks to @HoaS for getting me interested in systemd timers and services. I've kept your .timer code as-is, but tweaked the .service slightly /etc/systemd/system/pepperflash-adobe.service:

[Unit]
Description=Check Adobe for pepperflash upgrade.
OnFailure=notify-failure@The\x20Adobe\x20Flash\x20update\x20script\x20returned\x20an\x20error.\x0asudo\x20journalctl\x20\x2du\x20pepperflash\x2dadobe\x20for\x20details.service

[Service]
Type=oneshot
ExecStart=/usr/bin/update-pepperflashplugin-adobe-nonfree --upgrade

I've changed the type from simple to oneshot as it seemed more appropriate and still works. I wondered about adding Nice=5 to make it less intrusive, but am not sure...
Also added a service to handle failures /etc/systemd/system/notify-failure@.service :

[Unit]
Description=Send failure notification
[Service]
Type=oneshot
ExecStart=/usr/bin/notify-broadcast "Service Failed" "%I" --icon=dialog-erro

This uses the experimental notify-broadcast script here: https://forums.bunsenlabs.org/viewtopic.php?id=2673 and can take calls from any systemd service.

Does that all look OK to you?

Head_on_a_Stick · 2016-09-02 22:26:43

^ Looks fantastic, good work

May I ask why "Type=oneshot" was deemed preferable?

Subsequent unit files are not run until completion of that type of .service so it may delay the boot process.

johnraff · 2016-09-05 04:08:06

Head_on_a_Stick wrote:

May I ask why "Type=oneshot" was deemed preferable?

You understand, this was the product of a crash course in systemd services and friends, and reading the docs, 'oneshot' somehow seemed appropriate. I just trusted systemd to do the right thing. I did Read Somewhere™ that 'simple' services would be considered to have failed if they exit, but haven't so far found any evidence of that. Either type seems to work OK.

'oneshot' doesn't seem to be holding up the boot process at all. Journalctl shows the script's output mingled in with all the other startup processes. A chunk:

Sep 05 08:49:09 bunsen1 exim4[601]: Starting MTA: exim4.
Sep 05 08:49:10 bunsen1 dbus[609]: [system] Activating via systemd: service name='org.fr
Sep 05 08:49:10 bunsen1 update-pepperflashplugin-adobe-nonfree-test[954]: Installed vers
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> (eth0): link connected
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> (eth0): device state change: unavail
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Auto-activating connection 'Wired co
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) starting connectio
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 1 of 5 (Devi
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 1 of 5 (Devi
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> (eth0): device state change: disconn
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> NetworkManager state is now CONNECTI
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 2 of 5 (Devi
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 1 of 5 (Devi
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 2 of 5 (Devi
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> (eth0): device state change: prepare
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 2 of 5 (Devi
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 3 of 5 (IP C
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 2 of 5 (Devi
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> Activation (eth0) Stage 3 of 5 (IP C
Sep 05 08:49:10 bunsen1 NetworkManager[592]: <info> (eth0): device state change: config 
Sep 05 08:49:10 bunsen1 kernel: r8169 0000:02:00.0 eth0: link up
Sep 05 08:49:10 bunsen1 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sep 05 08:49:10 bunsen1 update-pepperflashplugin-adobe-nonfree-test[954]: You already ha

Actually, I'd rather emulate cron which runs "daily" jobs 5 min after startup. More RTFM...
What do you think of Nice=5 BTW?

#1 2016-07-23 21:10:30

[DONE] pepperflash-plugin-adobe-nonfree

#2 2016-07-24 08:34:13

Re: [DONE] pepperflash-plugin-adobe-nonfree

#3 2016-07-24 15:58:04

Re: [DONE] pepperflash-plugin-adobe-nonfree

#4 2016-07-25 03:30:50

Re: [DONE] pepperflash-plugin-adobe-nonfree

#5 2016-07-25 08:49:49

Re: [DONE] pepperflash-plugin-adobe-nonfree

#6 2016-07-29 06:03:49

Re: [DONE] pepperflash-plugin-adobe-nonfree

#7 2016-07-29 07:09:06

Re: [DONE] pepperflash-plugin-adobe-nonfree

#8 2016-07-29 07:25:23

Re: [DONE] pepperflash-plugin-adobe-nonfree

#9 2016-07-29 07:47:23

Re: [DONE] pepperflash-plugin-adobe-nonfree

#10 2016-07-29 08:53:09

Re: [DONE] pepperflash-plugin-adobe-nonfree

#11 2016-08-13 02:30:40

Re: [DONE] pepperflash-plugin-adobe-nonfree

#12 2016-08-16 08:02:39

Re: [DONE] pepperflash-plugin-adobe-nonfree

#13 2016-08-18 07:27:21

Re: [DONE] pepperflash-plugin-adobe-nonfree

#14 2016-08-18 20:46:32

Re: [DONE] pepperflash-plugin-adobe-nonfree

#15 2016-08-19 07:32:40

Re: [DONE] pepperflash-plugin-adobe-nonfree

#16 2016-08-19 07:34:44

Re: [DONE] pepperflash-plugin-adobe-nonfree

#17 2016-08-21 03:16:39

Re: [DONE] pepperflash-plugin-adobe-nonfree

#18 2016-09-02 08:44:08

Re: [DONE] pepperflash-plugin-adobe-nonfree

#19 2016-09-02 22:26:43

Re: [DONE] pepperflash-plugin-adobe-nonfree

#20 2016-09-05 04:08:06

Re: [DONE] pepperflash-plugin-adobe-nonfree

Board footer