Re: converting my local site to be https only access

[Felix Dietrich]

Gene Heskett  writes:

> Where can I find a tut that is a complete instruction set to have it do 
> an auto-redirect to itself, but using the "s" stuff regardless of the 
> accessing client as long as the client can handle the https stuff this 
> conversion will return to the client?

For the apache webserver, which I am assuming you are using, I found

https://wiki.apache.org/httpd/RedirectSSL

which describes how to permanently redirect clients to an encrypted
connection.  Clients without the capability to use SSL encryption will
not be able to see the contents of your site.

> I tried putting those 3 lines quoted numerous times at the bottom of the 
> httpd/conf/httpd.conf, but that killed local access so I assume it also 
> killed external access too.  And its failure did not generate an 
> error.log entry.

Which 3 lines are you referring to?  I cannot see any lines that look
like they represent configuration file syntax in your message.

> Something was said about the AllowRedirect settings in httpd.conf, but it 
> did not specify what to change it to.

Where was something said about AllowRedirect?  What was stated exactly?

> URL to the best tut please.

As much as I enjoy a bit of social interaction: are you abusing us to do
your internet searches for you?  Searching for "SSL redirect apache"
yields plenty of results.  Part of the "joy" of the computer hobby is to
wheat out obsolete information, identify the wrong, and copy and paste
the slightly less wrong.  I also won't judge anything to be "the best" –
unless it is my own of course. :-p

--
Felix Dietrich

Re: Firefox: security vs flexibility or rtfm?

[Fungi4All]

 Original Message 
Subject: Re: Firefox: security vs flexibility or rtfm?
From: mcop...@straitcity.com

>We only need one browser to work as these
>tasks are all performed in house. Just seemed like there must be a lot
>of old equipment with embedded HTTP servers out there that clever
>people keep working with OSS and chewing gum. But it's an imperfect
>world and no one can eliminate risk completely--we may just have to be
>vigilant.

Qupzilla works really well and is light on resources as it is pretty uncomplex 
to configure
https://github.com/QupZilla/qupzilla

Re: Old, stale bug reports (bug triage)

[Felix Dietrich]

songbird  writes:

>   does installing package how-can-i-help help?

Thanks for the suggestion.  I will have to spent some time going through
that list and see if I can find anything that I am able to do.

--
Felix Dietrich

Re: Old, stale bug reports (bug triage)

[Felix Dietrich]

Jonathan Dowland  writes:

> On Wed, Apr 26, 2017 at 02:53:28AM +0200, Felix Dietrich wrote:

> When closing, annote the bug with found/fixed version information.
> If you are using the bts command-line helper, you could do
> (for the ficftional bug number ABCDEF, which was found in a version
> 2016.15-4, and fixed in a version 2017.4-1):
>
>   bts found ABCDEF 2016.15-4 , fixed it 2017.4-1 , done it 2017.4-1

I hadn't come across that helper program, yet.  Thank you.

> At the end of the day, if the maintainer disagrees, they can reopen the
> bug.

I followed Ben Finney's advice and sent an email to the report
requesting information regarding the current state of it.  I will wait
awhile for a response before I am going to close the bug report.

> Thank you for wanting to make Debian better!

Thank you for doing so already.

--
Felix Dietrich

Re: Quest Software Clients

[Fungi4All]

> From: elena@ameriummail.com
> Please let me know your thoughts and I will get back to your with more 
> information for the same

Back to mine what?

> If you are not the right person, feel free to forward this email to the right 
> person in your organization.

I did, I'll let her handle it! I am the left person.

> Warm Regards,
> Elena Roy

Warmer regards,
devian

Re: converting my local site to be https only access

[Gene Heskett]

On Saturday 29 April 2017 04:05:01 Felix Dietrich wrote:

> Gene Heskett  writes:
> > Where can I find a tut that is a complete instruction set to have it
> > do an auto-redirect to itself, but using the "s" stuff regardless of
> > the accessing client as long as the client can handle the https
> > stuff this conversion will return to the client?
>
> For the apache webserver, which I am assuming you are using, I found
>
> https://wiki.apache.org/httpd/RedirectSSL
>
> which describes how to permanently redirect clients to an encrypted
> connection.  Clients without the capability to use SSL encryption will
> not be able to see the contents of your site.
>
> > I tried putting those 3 lines quoted numerous times at the bottom of
> > the httpd/conf/httpd.conf, but that killed local access so I assume
> > it also killed external access too.  And its failure did not
> > generate an error.log entry.
>
> Which 3 lines are you referring to?  I cannot see any lines that look
> like they represent configuration file syntax in your message.
>
> > Something was said about the AllowRedirect settings in httpd.conf,
> > but it did not specify what to change it to.
>
> Where was something said about AllowRedirect?  What was stated
> exactly?
>
> > URL to the best tut please.
>
> As much as I enjoy a bit of social interaction: are you abusing us to
> do your internet searches for you?  Searching for "SSL redirect
> apache" yields plenty of results.  Part of the "joy" of the computer
> hobby is to wheat out obsolete information, identify the wrong, and
> copy and paste the slightly less wrong.  I also won't judge anything
> to be "the best" – unless it is my own of course. :-p
>
Chuckle, point taken, used your search string and got smarter hits for 
apache2.  Since my domain registrar is namecheap, I'm reading this link:


The recommended commands, and responses:

sudo a2enmod rewrite
[sudo] password for gene: 
Enabling module rewrite.
To activate the new configuration, you need to run:
  service apache2 restart

gene@coyote:/etc/httpd/conf$ sudo a2enmod ssl
Enabling module ssl.
See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure 
SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  service apache2 restart


On restarting apache2, I get this error report on screen but the 
error.log is not showing the attempted restart.
Error shown:

Syntax error on line 71 of /etc/apache2/mods-enabled/ssl.conf:
Invalid command 'Header', perhaps misspelled or defined by a module not 
included in the server configuration
Action 'start' failed.

That files line 71: region
68:SSLCipherSuite AES128+EECDH:AES128+EDH
69:SSLHonorCipherOrder on # enable only secure protocols: SSLv3 and 
TLSv1, but not SSLv2
70:SSLProtocol -all +TLSv1
71:Header always set Strict-Transport-Security "max-age=63072000; include 
SubDomains"
72:Header alway set X-Frame-Options DENY

Being big dummy, whats this tell me?  So I read the file it recommends, 
which contains 2 more commands:
a2ensite default-ssl
a2enmod ssl
which appear to have worked, but it still will not restart.

The next recommended command is:

If you install the ssl-cert package, a self-signed certificate will be
automatically created using the hostname currently configured on your 
computer.
You can recreate that certificate (e.g. after you have changed /etc/hosts 
or
DNS to give the correct hostname) as user root with:

make-ssl-cert generate-default-snakeoil --force-overwrite

But this brings up a question:
The hostname of this computer doesn't match the name in the sig, my whole 
home networks domain name is coyote.den, and this machine is 
coyote.coyote.den.  Since its all behind a dd-wrt install, and its not 
even running on a normal port number, this to bypass the ususal port 80 
blocking the ISP's do in order to force you to use their servers at X$ a 
month, and to honor one of the cpu industries most enforced secrets 
ever, which is the Hitachi HD63C09, a clone of the Moto 6809, but which 
we have discovered is many times smarter. Hence the port:6309 in the 
sig, and the only port forwarded to this machine.

So in internal name and the one in the sig don't match?
So which name will it use if I run the above cert generator command?

 Ah, reading further, thats addressed by:

To create more certificates with different host names, you can use

make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /path/to/cert-file.crt

This will ask you for the hostname and place both SSL key and certificate 
in
the file /path/to/cert-file.crt . Use this file with the 
SSLCertificateFile
directive in the Apache config (you don't need the SSLCertificateKeyFile 
in
this case as it also contains the key). The file /path/to/cert-file.crt 
should
only be readable by root. A good directory to use for the additional
certificates/keys is /etc/ss

Re: Old, stale bug reports (bug triage)

[Brian]

On Sat 29 Apr 2017 at 14:14:01 +0200, Felix Dietrich wrote:

> songbird  writes:
> 
> >   does installing package how-can-i-help help?
> 
> Thanks for the suggestion.  I will have to spent some time going through
> that list and see if I can find anything that I am able to do.

As Jonathan Dowland said

 > . there are far, far too many bug reports and not enough people
 > working on them. This is one area that people can really make a
 > difference in contributing to Debian.

Never a truer word was said. The bug count increases and the bug record
for well-used packages continues to increase. For a start, this makes it
difficult for a user with a problem to sort the wheat from the chaff.
Culling the number of reports is a task which does not necessarily
require much time or deep understanding of the package or the way the
software works. Just some commonsense and the support of the maintainer.
The result would be a cleaner and more useful database of bug reports.

For example, are reports about issues on Squeeze relevant today? The
chances are many will have been fixed by now. Perhaps a lttle judgement
would be required, but, in all probability, most could be closed. Wheezy
too. Consult the submitter to see whether the bug is still reproducible
in unstable. No reply? Close the report after a reasonable time has
passed.

Five-year old wishlist bugs? Read; come to a judgement; close (giving a
sound, decent reason); most are past their sell-by date.

-- 
Brian.

Re: How to Run a Command on Screensaver Activation, Only After User Interaction that Session?

[Kent West]

On Thu, Apr 27, 2017 at 9:27 PM, Felix Dietrich <
felix.dietr...@sperrhaken.name> wrote:

> Kent West  writes:
>
> > On Wed, Apr 26, 2017 at 4:52 PM, Kent West  wrote:
> > I've got 90% of it done, but I need it to logout after a certain
> > time of inactivity, but only after the computer has been used at
> > least once since the last start of X (otherwise it'll just be in a
> > slow loop of restarting X).
> >
> > - boot into X
> > - sit idly for 20 minutes, 2 hours, 3 days, whatever, screensaver
> >   running, until a guest comes up and uses the kiosk
>
> Do you mean the display manager is running waiting for a user to log in,
> possibly allowing a passwordless guest login?


No. There is no login manager; the system boots straight into X, and fires
up Firefox to its home page, and then waits for a passerby to come use it
to web-browse.


> Upon login the display
> manager executes an initialisation script, possibly .xinitrc.  In this
> script you can set up the kiosk session:
>
> - start the program/script that will forcibly log the user out once
>   a certain time has passed.
> - start a program/script to monitor the xscreensavers state
> - start some basic programs (window manager, panels) so that a user
>   can actually do something
> - whatever else you can think of
>

Yes. This is exactly what I have done. What I needed (and have since solved
- below) was help working out the syntax of determining human interaction
with X.


>
> You may also want to consider that a user probably should not be able to
> edit the initialisation script (xinitrc) or kill the program/script that
> will exit the session automatically after a certain time has passed.
>

In my current setup, the current user can do either of these things, but
not permanently; his changes are lost upon a restart of X, so the changing
of .xinitrc is a non-issue. The ability to kill the script that will exit
the session automatically after a certain time is a bit more of an issue,
but not enough in my situation to warrant overthinking it at this time.
Meh, compromise.


>
> When using a display manager the FRESH_X variable might not be
> necessary.
>
> > In my .xinitrc, I have
> >
> > export FRESH_X=TRUE
> >
> > Then I want to have a script that sits and waits for a keypress or a
> > mouse activity; this is where I need the syntax help.
>
> When you refer to "script" do you mean a separate script file that you
> call or simply more commands following the shells "export" command?
>
> > When that script sees keyboard or mouse activity, it will export
> > FRESH_X=FALSE
>
> In case you are talking of a script file you run (instead of source [1])
> be aware that the value of environment variables is not shared among
> processes: a parent process can pass environment variables to a child
> process on execution, but once the child exists both parent and child
> have their own copy of the environment.
>

Yeah, this is part of what I was running into. But my solution turned out
to be exceptionally easy (it just took me 30 hours of tinkering to figure
it out, pfft).

>
>
>
> > But I need help with the syntax of checking for a keypress or mouse
> > activity. I've looked at xinput and xev and another tool something
> > like xenv, but I can't figure out the syntax in a bash if/then
> > statement.
>
> The following snipped can be used to block further script execution
> until xinput reports an event.  It reads lines from xinput until it
> encounters a line starting with "EVENT" using, instead of the "if"
> statement, the "case" statement [2] , which supports a simple form of
> pattern matching.
>
> xinput --test-xi2 --root | while read line
> do
> case $line in
> EVENT*)
> break
> ;;
> esac
> done
>


The problem is that xinput reports several EVENTs on startup of the
utility, so I had to figure out a way to do finer-grained testing. My
solution is below.


>
> > I'll configure the xscreensaver-command --watch to watch for the
> > screen saver to go BLANK, and when it does I check the status of
> > FRESH_X ; if FRESH_X is FALSE, and the screensaver activates, I can
> > set a 10-second time, check again to make sure the screensaver is
> > still active, and then run my logout.
>
> Searching the web, I found the xautolock [3] program.  You may be able
> to use its "-killer", "-killtime", "-locker", "-time" parameters to
> realise your kiosk idea and save you some scripting.
>
>

Had I seen this earlier, I would have looked into xautolock. But as it is,
here's my solution:

My kiosk user's .xinitrc:

=
# Start watching for human interaction with this machine
/home/kiosk/bin/wipe_profile.sh &

 # Start xfce4
xfce4-session &

 # Start Firefox Extended Support Release; quit X when it quits
/usr/bin/firefox-esr
=


And my wipe_profile.sh script (minus comments):

=
kioskdir=/home/kiosk/
backupdir=/opt/kiosk/

rsy

Re: Firefox: security vs flexibility or rtfm?

[Mark Copper]

On Fri, Apr 28, 2017 at 9:14 PM, Andy Smith  wrote:
> Hi Mark,
>
> I think Mozilla's position is reasonable since if you allow this
> sort of thing to remain possible, nobody will fix anything. Broken
> software will ship with instructions for the users to "just make an
> exception".
>
> Would it be feasible to put a proxy in front of the HTTP-only
> service, that consumes HTTP on its backend and exposes HTTPS on its
> frontend?
>
> That way, the burden is on the administrator rather than the
> end-user, which is probably a fairer division of labour.

I think this is spot on. Thank you. A quick search shows Apache
modules mod_proxy and mod_ssl as a viable path. And with cheap single
board computers preloaded with Debian and Apache, old gear stays
economically viable. Cool.

Your point about division of labor is well-taken. While I initially
bridled at free software not being free, I understand that a publicly
distributed browser has special responsibilities--especially when
there exist secure solutions to a given problem just a little further
afield.

Mark

Re: converting my local site to be https only access

[Jochen Spieker]

Gene Heskett:
> On Saturday 29 April 2017 04:05:01 Felix Dietrich wrote:
>> Gene Heskett  writes:
>> 
>>> Where can I find a tut that is a complete instruction set to have it
>>> do an auto-redirect to itself, but using the "s" stuff regardless of
>>> the accessing client as long as the client can handle the https
>>> stuff this conversion will return to the client?

What you want to do requires that you understand the basics of Apache's
configuration mechanism. You should really start with that.

http://httpd.apache.org/docs/2.4/en/getting-started.html
http://httpd.apache.org/docs/2.4/en/bind.html
http://httpd.apache.org/docs/2.4/en/configuring.html 
http://httpd.apache.org/docs/2.4/en/urlmapping.html
http://httpd.apache.org/docs/2.4/en/vhosts/

That's really just the basics so you know where to put random things you
find on the internet. For your use case, these should also be helpful:

http://httpd.apache.org/docs/2.4/en/ssl/
http://httpd.apache.org/docs/2.4/en/rewrite/

What the upstream Apache documentation does not mention (or care about)
is that Debian has its own way of splitting up Apache configuration
files. If a random (not Debian- or Ubuntu-specific) tutorial tells you
to change your httpd.conf then this is most certainly not the way to do
it in Debian.

>>> I tried putting those 3 lines quoted numerous times at the bottom of
>>> the httpd/conf/httpd.conf, but that killed local access so I assume
>>> it also killed external access too.  And its failure did not
>>> generate an error.log entry.

The bottom of your httpd.conf might be the wrong place to put it. It
really depends on your local configuration which we do not know. Do you
have a plain Debian installation that you did yourself or do you use an
image from a hoster or any other company? What changes have you done to
your configuration?

What Debian expects most admins to do is drop their own virtual host
definitions into /etc/apache2/sites-available/ and use a2ensite to
enable them. Global configuration directives can be placed in
conf-available/ (use a2enconf).

>>> Something was said about the AllowRedirect settings in httpd.conf,
>>> but it did not specify what to change it to.

Don't touch httpd.conf, it will probably not do what you want to
achieve. Instead, edit the virtual host you are using.

> Chuckle, point taken, used your search string and got smarter hits for 
> apache2.  Since my domain registrar is namecheap, I'm reading this link:
> 

Your domain registrar is irrelevant here. Look for
Debian/Ubuntu-specific tutorials after reading up on the basics.

> Syntax error on line 71 of /etc/apache2/mods-enabled/ssl.conf:
> Invalid command 'Header', perhaps misspelled or defined by a module not 
> included in the server configuration
> Action 'start' failed.

Apparently the header module is not enabled in your configuration. You
can do so by running "a2enmod headers".

> If you install the ssl-cert package, a self-signed certificate will be
> automatically created using the hostname currently configured on your 
> computer.

If your machine is publicly available, there is really no reason anymore
to use self-signed certificates -- except for testing, probably. If your
configuration works with your self-signed certificate, you should
consider using Let's Encrypt.

> So in internal name and the one in the sig don't match?
> So which name will it use if I run the above cert generator command?

Nowadays you can run more than one VirtualHosts even with only one IP
address. You just set up regular virtual hosts which use their own
certificates.

I cannot comment on the other errors you are getting, but (just in case
I didn't stress it enough :)) I think your life will become a lot easier
once you master the basics of Apache. The creation of SSL certificates
actually becomes a lot easier with Let's Encrypt.

J.
-- 
In this bunker there are women and children. There are no weapons.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: converting my local site to be https only access

[Gene Heskett]

On Saturday 29 April 2017 14:21:27 Jochen Spieker wrote:

> Gene Heskett:
> > On Saturday 29 April 2017 04:05:01 Felix Dietrich wrote:
> >> Gene Heskett  writes:
> >>> Where can I find a tut that is a complete instruction set to have
> >>> it do an auto-redirect to itself, but using the "s" stuff
> >>> regardless of the accessing client as long as the client can
> >>> handle the https stuff this conversion will return to the client?
>
> What you want to do requires that you understand the basics of
> Apache's configuration mechanism. You should really start with that.
>
> http://httpd.apache.org/docs/2.4/en/getting-started.html
> http://httpd.apache.org/docs/2.4/en/bind.html
> http://httpd.apache.org/docs/2.4/en/configuring.html
> http://httpd.apache.org/docs/2.4/en/urlmapping.html
> http://httpd.apache.org/docs/2.4/en/vhosts/
>
> That's really just the basics so you know where to put random things
> you find on the internet. For your use case, these should also be
> helpful:
>
> http://httpd.apache.org/docs/2.4/en/ssl/
> http://httpd.apache.org/docs/2.4/en/rewrite/
>
> What the upstream Apache documentation does not mention (or care
> about) is that Debian has its own way of splitting up Apache
> configuration files. If a random (not Debian- or Ubuntu-specific)
> tutorial tells you to change your httpd.conf then this is most
> certainly not the way to do it in Debian.
>
> >>> I tried putting those 3 lines quoted numerous times at the bottom
> >>> of the httpd/conf/httpd.conf, but that killed local access so I
> >>> assume it also killed external access too.  And its failure did
> >>> not generate an error.log entry.
>
> The bottom of your httpd.conf might be the wrong place to put it. It
> really depends on your local configuration which we do not know. Do
> you have a plain Debian installation that you did yourself or do you
> use an image from a hoster or any other company? What changes have you
> done to your configuration?
>
> What Debian expects most admins to do is drop their own virtual host
> definitions into /etc/apache2/sites-available/ and use a2ensite to
> enable them. Global configuration directives can be placed in
> conf-available/ (use a2enconf).
>
> >>> Something was said about the AllowRedirect settings in httpd.conf,
> >>> but it did not specify what to change it to.
>
> Don't touch httpd.conf, it will probably not do what you want to
> achieve. Instead, edit the virtual host you are using.
>
> > Chuckle, point taken, used your search string and got smarter hits
> > for apache2.  Since my domain registrar is namecheap, I'm reading
> > this link:
> >  >8/redirect-to-https-on-apache>
>
> Your domain registrar is irrelevant here. Look for
> Debian/Ubuntu-specific tutorials after reading up on the basics.
>
> > Syntax error on line 71 of /etc/apache2/mods-enabled/ssl.conf:
> > Invalid command 'Header', perhaps misspelled or defined by a module
> > not included in the server configuration
> > Action 'start' failed.
>
> Apparently the header module is not enabled in your configuration. You
> can do so by running "a2enmod headers".
>
Not being fam with this a2enmod thing, I just used mc to make a softlink.  
That moved the error and changed it a wee bit, to line 72, which had the 
keyword always spelled alway. Fixed, start right up. I can only see it 
at localhost, so I've no clue if the link in my sig works or not.

If it redirects to https and the front page pix loads, I'm good to go I 
think.

> > If you install the ssl-cert package, a self-signed certificate will
> > be automatically created using the hostname currently configured on
> > your computer.

Which is not the same as the dns servers returns.
>
> If your machine is publicly available, there is really no reason
> anymore to use self-signed certificates -- except for testing,
> probably. If your configuration works with your self-signed
> certificate, you should consider using Let's Encrypt.
>
> > So in internal name and the one in the sig don't match?
> > So which name will it use if I run the above cert generator command?
>
> Nowadays you can run more than one VirtualHosts even with only one IP
> address. You just set up regular virtual hosts which use their own
> certificates.
>
> I cannot comment on the other errors you are getting, but (just in
> case I didn't stress it enough :)) I think your life will become a lot
> easier once you master the basics of Apache. The creation of SSL
> certificates actually becomes a lot easier with Let's Encrypt.

Those are done I believe:
root@coyote:/etc/httpd/conf# ls -l /etc/ssl/private/
total 8
lrwxrwxrwx 1 root root   18 Apr 29 10:27 fba0a812 -> 
ssl-cert-genes.key
-rw--- 1 root root 2798 Apr 29 10:27 ssl-cert-genes.key
-rw-r- 1 root ssl-cert 1704 Apr 29 08:46 ssl-cert-snakeoil.key

Unless thats not enough.
>
> J.

Thanks, Jochen Spieker.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defe

Re: Old, stale bug reports (bug triage)

[Brian]

On Sat 29 Apr 2017 at 14:29:19 +0200, Felix Dietrich wrote:

> Jonathan Dowland  writes:
> 
> > On Wed, Apr 26, 2017 at 02:53:28AM +0200, Felix Dietrich wrote:
> 
> > When closing, annote the bug with found/fixed version information.
> > If you are using the bts command-line helper, you could do
> > (for the ficftional bug number ABCDEF, which was found in a version
> > 2016.15-4, and fixed in a version 2017.4-1):
> >
> > bts found ABCDEF 2016.15-4 , fixed it 2017.4-1 , done it 2017.4-1
> 
> I hadn't come across that helper program, yet.  Thank you.
> 
> > At the end of the day, if the maintainer disagrees, they can reopen the
> > bug.
> 
> I followed Ben Finney's advice and sent an email to the report
> requesting information regarding the current state of it.  I will wait
> awhile for a response before I am going to close the bug report.

While you are there you could consider closing the five wishlist
reports. All are from 2009/2010. 7/8 years has passed and no one
has stepped forward to respond significantly to these enhancement
requests. They are highly unlikely to be fulfilled; the reports
serve no purpose.

Has upstream altered the software to accomodate them? How likely
is it that anyone will? The reports will linger in the BTS for the
forseeable future. Their disappearence will not reflect on the
quality of Debian or the good intentions of the submitters. Get
rid of the reports.

Suppose 100 readers of this list did the same for 5 other packages
each. That would be 2500 closed bugs. Then the same readers get
carried away and look at the other bugs in their chosen packages.

Where could this end? 25,000 closed bugs? It doesn't happen until
users make it happen. Maintainers can only do so much.

-- 
Brian.