pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[EmeraldDeer]

rc.func is only throwing away messages generated when stubby is started or stopped. Logging is a completely separate function.

Perhaps logging should be a completely separate function. But Stubby only uses standard error. I do not follow your argument.
EDIT: Oops, I posted Stubby content in the Pixelserv thread. Sorry.

 

[cmkelley]

Perhaps logging should be a completely separate function. But Stubby only uses standard error. I do not follow your argument.

If that is true, then even without the redirect stubby would never write to the logfile, it would write those messages to the screen only. A daemon (ntpd, syslogd (or syslog-ng), httpd, etc.) puts itself into memory and returns control to the shell. For a daemon, the rc.func line is only throwing away the messages when a daemon is launched or stopped, i.e. those messages generated between the time the command is issued to the daemon, and when control passes back to shell. It's not redirecting all output for as long as the daemon is active, it doesn't work that way.

The '&' at the end of the calling function is so the shell doesn't have to wait for the daemon to do it's thing or fail, some daemons may take longer to get going, or wait for a network connection, or whatever. Without that, a daemon that hung would hang the entire system. The system doesn't have to wait for them to do their thing before doing its next thing. The '&' is not a magic way to turn a program into a daemon.

 

[kvic]

Previously mentioned in this thread, a gentleman has created a Docker image for pixelserv-tls. I see it has accumulated over 10K+ downloads. I'm a bit shocked. Belated realisation of Docker's popularity these days.

 

[gattaca]

Previously mentioned in this thread, a gentleman has created a Docker image for pixelserv-tls. I see it has accumulated over 10K+ downloads. I'm a bit shocked. Belated realisation of Docker's popularity these days.

Containers are the "new VMs" and with Kubernetes, you can build your ecosystem.

Not surprised. It's only escalating. All the clouders are practically stumbling over each other to implement containerized infrastructure. It's projected to overtake "VMs" a few years out and loosen Dell/EMC/VMware's grip on the IT virtualization industry.

ABC - GCP, AWS - ECS, MSoft - AKS, IBM-ICKS, ...

 

[kvic]

Containers are the "new VMs" and with Kubernetes, you can build your ecosystem.

Not surprised. It's only escalating. All the clouders are practically stumbling over each other to implement containerized infrastructure. It's projected to overtake "VMs" a few years out and loosen Dell/EMC/VMware's grip on the IT virtualization industry.

ABC - GCP, AWS - ECS, MSoft - AKS, IBM-ICKS, ...

Very interesting and all these seem happen in the past few years..

 

[Zastoff]

New version 2.2.1-1 (OpenSSL 1.1.1b)
Thank you Kvic

edit:
This release keeps the same 2.2.1 version but with rebuilt timestamp, "compiled: Feb 27 2019 13:10:XX

 

[L&LD]

New version 2.2.1-1 (OpenSSL 1.1.1b)
Thank you Kvic

I did the update, but it shows the same version in amtm 1.8?

I used the '4' Update pixelserv-tls beta v2.2.1 option at the main menu of amtm. Then I selected the '2' option and then the '1' option for my RT-AC3100.

Maybe just a small bug?

 

[HardCat]

I did the update, but it shows the same version in amtm 1.8?

I used the '4' Update pixelserv-tls beta v2.2.1 option at the main menu of amtm. Then I selected the '2' option and then the '1' option for my RT-AC3100.

From @kvic website:

This release keeps the same 2.2.1 version but with rebuilt timestamp, "compiled: Feb 27 2019 13:10:XX".

Cheers!

 

[Zastoff]

I did the update, but it shows the same version in amtm 1.8?

I used the '4' Update pixelserv-tls beta v2.2.1 option at the main menu of amtm. Then I selected the '2' option and then the '1' option for my RT-AC3100.

Maybe just a small bug?

• Upgraded OpenSSL to 1.1.1b for pixelserv-tls static binaries. OpenSSL 1.1.1b provides better compatibility for client browsers and apps.
• Added logging on LEVEL 2 when a client disconnects before a response is sent i.e. a 'cly' event

This release keeps the same 2.2.1 version but with rebuilt timestamp, "compiled: Feb 27 2019 13:10:XX".

https://kazoo.ga/pixelserv-tls/

 

[EmeraldDeer]

I did the update, but it shows the same version in amtm 1.8?

I used the '4' Update pixelserv-tls beta v2.2.1 option at the main menu of amtm. Then I selected the '2' option and then the '1' option for my RT-AC3100.

Maybe just a small bug?

Yes, upgrading to Release 2.2.1-1 (2019-2-27) does not work through amtm/Diversion presumably because the version did not change.

Thankfully the installer script does the upgrade without recreating the pixelserv Certificate Authority key and certificate. I am using the static build:

_binfavor=static sh -c "$(wget -qO - https://kazoo.ga/pixelserv-tls/install-beta.sh)"

Oddly, the upgrade is not reflected in the output of menu item "show pixelserv-tls info". It is, however, reflected in the date on the first line of the servstats webpage.

pixelserv-tls 2.2.1 (compiled: Dec 29 2018 15:01:07 flags: tfo tls1_3) options: 192.168.50.254 -l 4
pixelserv-tls 2.2.1 (compiled: Feb 27 2019 13:11:04 flags: tfo tls1_3) options: 192.168.50.254 -l 3

 

[L&LD]

Yes, upgrading to Release 2.2.1-1 (2019-2-27) does not work through amtm/Diversion presumably because the version did not change.

Thankfully the installer script does the upgrade without recreating the pixelserv Certificate Authority key and certificate. I am using the static build:

_binfavor=static sh -c "$(wget -qO - https://kazoo.ga/pixelserv-tls/install-beta.sh)"

Oddly, the upgrade is not reflected in the output of menu item "show pixelserv-tls info". It is, however, reflected in the date on the first line of the servstats webpage.

pixelserv-tls 2.2.1 (compiled: Dec 29 2018 15:01:07 flags: tfo tls1_3) options: 192.168.50.254 -l 4
pixelserv-tls 2.2.1 (compiled: Feb 27 2019 13:11:04 flags: tfo tls1_3) options: 192.168.50.254 -l 3

Actually, I did do the update through amtm (from the main menu), not from within the Diversion menu.

I just re-installed the beta and it found the update and updated itself. Just doesn't report the updated version in amtm though.

 

[EmeraldDeer]

Actually, I did do the update through amtm (from the main menu), not from within the Diversion menu.

I just re-installed the beta and it found the update and updated itself. Just doesn't report the updated version in amtm though.

That is interesting. I used Diversion but not amtm. Why? Because if I recall correctly, past attempts to upgrade entware would throw an error advising to update through Diversion because that is where the logic is which protects special static builds from being overwritten by Entware updates. Pixelserv is not Entware but that is why I tried Diversion.

 

[L&LD]

That is interesting. I used Diversion but not amtm. Why? Because if I recall correctly, past attempts to upgrade entware would throw an error advising to update through Diversion because that is where the logic is which protects special static builds from being overwritten by Entware updates. Pixelserv is not Entware but that is why I tried Diversion.

Yes, I tried it initially there too, but I did not see any notice of it upgrading anything.

But when simply re-running the 'beta' installer from the main amtm screen, I saw it picked up the new script.

 

[elorimer]

That is interesting. I used Diversion but not amtm. Why? Because if I recall correctly, past attempts to upgrade entware would throw an error advising to update through Diversion because that is where the logic is which protects special static builds from being overwritten by Entware updates. Pixelserv is not Entware but that is why I tried Diversion.

Nope, not close. We've been over this before. amtm - the SNBForum Asuswrt-Merlin Terminal Menu

 

[EmeraldDeer]

Nope, not close. We've been over this before. amtm - the SNBForum Asuswrt-Merlin Terminal Menu

Not close?

The reason I added the cautionary text is that when Entware (through amtm or manually) updates pixelserv-tls it did overwrite the S80 startscript and causes(ed) pixelserv-tls to not start. When doing it through Diversion, I make sure that won't happen.

 amtm 1.8                  by thelonelycoder

 RT-AX88U (aarch64) FW-384.9 @ 192.168.50.1

  The SNBForum Asuswrt-Merlin Terminal Menu

    SNBForum scripts
 1  open     Diversion v4.0.7
 2  install  dnscrypt installer
 3  update   Entware
 4  update   pixelserv-tls beta v2.2.1

 5  open     Skynet v6.7.8
 6  open     Stubby DNS v1.0.9
 7  open     YazFi v3.1.0

    amtm system tools
 dc remove   Disk check script   dcl show log
 fd run      Format disk
 rs enable   Reboot scheduler
 sw delete   Swap file /mnt/ent

    amtm options
 e  exit    u  update    r  remove   a  about
_____________________________________________

 Enter option  3

__________________| INFO |___________________

 This updates and upgrades Entware packages

 Note: Diversion is installed on this router.
 It's recommended to update Entware packages
 in Diversion using the  ep  option.
 Especially so when pixelserv-tls is installed.

_____________________________________________

 Continue? [1=Yes e=Exit]

 

[elorimer]

Not close. amtm has that warning because the entware packages often come with their own start scripts, which overwrite the carefully crafted diversion version of the pixelserv start script. @thelonelycoder has a separate menu in Diversion to upgrade pixelserv. Those start scripts have nothing to do with pixelserv's beta versions, which have a static build option. And that is why the beta install is in amtm.

 

[elorimer]

Upgraded OpenSSL to 1.1.1b for pixelserv-tls static binaries.

Kudos for linking to the changelog. I'd read the 1.1.1b version, but the link adds the new versioning. Oy.

 

[Makaveli]

I did the update with amtm and selected

2. Install Statically linked beta version

and everything is good no issues.

pixelserv-tls 2.2.1 (compiled: Feb 27 2019 13:10:51 flags: tls1_3

 

[kvic]

Looks like things in this thread work out very well!

Enjoy the refresh from OpenSSL, everyone!

 

[joe scian]

Hi Kvic
I am getting this error in amtm - when trying to update pixelserv - any ideas

pixelserv-tls: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

update pixelserv-tls beta vvlikely v.Kk (not running)