First the DSA key no longer working...

Yes I had that problem too.  Basically DSA (ssh-dss) is now considered too
weak.

You can enable it on the new machine.  or you can just create new keys
(such as ecdsa), and distribute a updated "authorised_keys" file.   That is
what I did,  I later plan to remove my old DSA keys.

Actually I had already come across it while trying to access a different
server, but found using the older RSA key worked. I could nto diagnose the
issue back then as I did not have read access to the system logs (not my
machine).  Now that I know what the problem is I created a ecdsa key for
that account, and all is good.

 ---
Second...  Kill (Destory Window) verses Delete Window

There are two ways X windows can remove a window (application) from the
display.

   Destory Window   -- which is essentially what xkill does, and typically
causes the application to 'terminate' with a X window, I/O error.
Programmically I found it very had to get applications to handle such a
situation!

  Delete Window  -- which is the event the application receives when the
user presses the 'X' on a application title bar.  Basically this askes the
application to remove that window (and exit if it is it's last window).
Basically it lets the cleanly cleanup and shutdown.

Now shutting down the X server (reset by the login manager when .xinitrc
script exits) does the first.  The Connection to the Window (and display)
just terminates in a very unfriendly manner.


So what can you do about it...

As part of my 'logout' sequence, I use an very old program call
"xclosedown" in my ".xinitrc" script.

This program attempts to first send a 'clean'   "Delete Window" event to
all open windows.

Then a few seconds later it sends a "Destroy Window" event to any windows
still running.


Actually I don't know why this small and simple "xclosedown" program isn't
more wide spread,  It is such a simple and useful program.

I found a list of copies of this program at...
   http://www.filewatcher.com/m/xclosedown.tar.gz.3714-0.html
But I can sent you my own copy of its sources if you want.
Actually I just re-compiled it for my new x86_64 FC24 machine, after fixing
minor 'GCC code warnings'.

It could probably even be re-created as a shell script, using other general
X window utilites. Though I can't seem to find a utility program (xdotool,
xwit, etc) that can send a 'delete window' event.       --- Challenge
anyone?


Why do I reset my display myself?

First it shuts things down in a more clean and application friendly manner.

And second, after xclosedown has run, my 'overly complicated' ".xinitrc"
script has a clean X window display.

At that point my script can then either
  1/ restart ALL may applications refresh, as if I just logged in
  2/ exit so the login manager can reset the display and prompt for a new
login,
  3/ Reboot my machine
  4/ poweroff my machine.
And yes I can do any of the 4 options via my on screen 'logout' button.
I don't depend on panels or window managers to handle this part!

PS: by doing things this why I can even change window managers, panels, or
anything else on my display without needing to logout all the time.  This
lets me try out new things AS I LIKE.

Then again, I have been using X Windows from the first public X9 release,
in 1988!  That is almost 30 years!



On Mon, Sep 19, 2016 at 12:41 AM, Aaron Sloman <a.slo...@cs.bham.ac.uk>
wrote:

>
> Olaf wrote:
>
> > I have found a few times that if you close the Firefox window, it
> > forgets all the tabs in it (optionally it warns you for that with a
> > pop-up). But if I Quit firefox (via the menu or Control-Q) it remembers
> > them.
> >
> > I am guessing from this that exiting X will do the equivalent of closing
> > the Firefox window, instead of choosing its Quit function.
>
> Yes that's the conclusion I had drawn, whereas an explicit 'kill' by user
> chooses the Quit function and firefox remembers the open tabs and windows
> (not kill -9).
>
> I mentioned previously that I had recently switched back to starting X from
> level 3, instead of going via level 5 (i.e. now avoiding using graphical
> login and xdm/gdm or whatever).
>
> I *think* my previously reported problems of keyboard input focus not
> always following the mouse have disappeared as a result. I have only been
> using the new startup procedure for a few days (on both laptop and desktop
> machines), so I can't yet be sure. As everything seems to be working ok
> without the previously mentioned xorg-x11-xinit-session package, I have
> not tried using it.
>
> Aaron
>
> PS
> Another (not window manager related) problem:
> My laptop was upgraded from Fedora 22 to 24 yesterday. I then found ssh
> login without password from other local machines no longer worked.
> After about two hours of wasted effort I eventually discovered that the
> defaults had changed.
>
> In case anyone else has this problem I found the answer here:
>
> https://www.digitalocean.com/community/questions/ssh-
> refused-sshd-2444-userauth_pubkey-key-type-ssh-dss-not-
> in-pubkeyacceptedkeytypes-preauth
>
>     For this specific error, you need to add "PubkeyAcceptedKeyTypes=+ssh-
> dss"
>     (without the quotations) to the bottom of your /etc/ssh/sshd_config
> file.
>
>

Reply via email to