This is the 4th time I have tried to send to the list but ff wants to insist I send it to mgb.
So I'm going to compose this the last time.
Re the sudo -E:
from wheezy thru jessie and stretch its been required since X would not allow root to use it without it, but I just went to a buster machine and I'll be dipped, it worked without the -E on a buster/xfce4 install.
But I've become quite fam with "sudo chown -R gene:gene /home/gene" to fix such wonky perms because of it. Why it took debian 3 major version updates to fix it boggles my mind.
Now, where was I. stuck in a one window jail cuz I can't get trinity to load and work.
What I do know is that if I'm not using gdm3, I lose sudo rights as lightdm and tdm-trinity all want an admin pw and that doesn't exist. my sudo pw doesn't work.
So lets start, one step at a time, what do I do to fix this?
Thanks Mike, gene
>apt is all you need for managing Debian packages, and your choice of
>non-GUI editor for editing config files.
All true IF you know exactly what you want. But synaptics ability to search is worth a lot.
And I use nano, a lot. sudo nano runs anywhere. As pointed out previously this is a rootless install, and I am in the sudo group. But lightdm nor tdm-trinity know that so I can't use sudo
then. So something is fubar, but what?
Thanks Mike, Gene
I'd love to make that work Felix, but at the moment I'm bouncing between a shell,
firefox and whatever I have the shell doing as I only have one, count 'em, workspace,
IOW tde isn't working.
I think its running either gnome or some leftovers from xfce4. And I lose sudo if I use
a non gdm3 window manager.
Thanks Felix, Gene
On Tue November 30 2021 02:46:14 Gene Heskett wrote:
> <snipped>
Hi Gene,
Please keep replies on list so they're available for others to see and
learn from or to correct my mistakes. I'm moving this back on list but
privacy rules prevent me from quoting to the list what you sent me off
list.
Bullseye is a great choice here and now.
You have told us that you have used "sudo -E ..." although you haven't
told us why you used "-E". What "-E" does is run as root but on your
own home folder, not root's. This can easily leave stuff in your home
folder which is owned by root and cannot be handled by your regular
user account and that can cause all kinds of breakage. You might be
able to fix it with something like "chown -R ..." and "chgrp -R ..."
but that might make things worse.
You have told us that you have gdm3, lightdm, and tdm-trinity on this
new install and you have also had kde installed but it is mostly removed
now. That ought to work but it is not really a good idea. Think about
what you need and only install what you need. Installing hundreds of
unneeded packages creates a lot more security vulnerabilities than
allowing a root login with a 16-character random password. You can
always block ssh root logins without blocking console root logins
because if the CIA is sitting at your physical keyboard you're pwned
already mate.
You really have two choices when installing Debian: a canned install
or an expert install. If you choose a canned install you're not TTBOMK
going to get RAID10. If you choose expert install you need to know
what you're doing. Over the years I've used HW RAID1, HW RAID5, SW
RAID1, and SW RAID5 but IIRC I've never used RAID10 and today IMNSHO
LVM is much better. But again you have to know what you're doing and why.
Whether you use RAID10 or LVM or mercury delay lines you're going to
have options in the Debian installer to format each FILESYSTEM. You
don't need to spend ten hours zeroing PARTITIONS.
So my advice to you is make a plan, do everything in the simplest
and most standard way possible except where you need something different,
and document exactly what you plan, what you do, and what happens.
We can't help you much if you spend a few hours knitting semi-random
stitches and then want us to help you turn it into a sweater.
One of the key decisions you will make will be systemd vs sysvinit.
I use sysvinit. If in doubt you should use systemd because it is
the canned standard solution and you don't want to deviate from that
without good reason. Just like you don't want to use "sudo -E"
without good reason.
Good luck Gene,
--Mike
Mike Bitd says what does this do that kmail can't?
This is synchronous with the arrival of a mail, so kmail doesn't freeze for 5 to 15 seconds while it does it. Puts it all in the background and kmail only freezes long enough to go get
it and sort it into the proper folder, a few milliseconds at worst case.
Its all part of my incoming mail, reducing my part to a mouse click to go to the next unread
msg.
Lesson from a frustrated teacher:
Computers are supposed to do work FOR you, not make more work. So make it do the
drudgery stuff by itself. So I write bash scripts.
One click to go to the next unread msg, one click to reply if I can help, and one click
to send my reply after typing it. Whats not to like? And this script has been running
here in various incarnations for at least a twenty years.
Originally used dcop but that fell out of favor a decade+ back up the log. Or when I
bailed out of fedora because fedora was always broken, but that was a good 15 years ago.
/lesson.
Thanks Mike, Gene
mailwatcher is this script:
#!/bin/bash
# set -x
# this was a test, was /bin/sh above, but /bin/sh is a softlink to /bin/dash
# REQUIRES your distros inotify-tools package, assume kde/kmail in use
# but might be adaptable to other agents too
# requires a ~/log directory, so mkdir it before running it
# you will also need to either do the housekeeping of this file, or
# figure out how to make logrotate do it for you.
WatchDir=/var/spool/mail/
# Setup temporary log
Log=mail.log
# put it in my home dir like fetchmail and procmail
Mlog=~/log
# in case it doesn't exist, make it
touch ${Mlog}/${Log}
# the command to send over dbus/dcop to make kmail pull the mailfile
#in /var/spool/mail
# First set method
Method=dcop
if [[ ${Method} = 'dbus' ]]
then
Cmd="/usr/bin/qdbus org.kde.kmail /KMail org.kde.kmail.kmail.checkMail"
fi
if [[ ${Method} = 'dcop' ]]
then
#or for dcop, use:
Cmd="/opt/trinity/bin/dcop kmail KMailIface checkMail"
fi
# Now, do forever
while :
do
sleep 1
if [ $(pidof -s kmail) ]
then
echo -n "Kmail is running " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
sleep 1 # delay to give kmail a chance to settle in
# only start fetchmail once!
if [ $(pidof -s fetchmail) ]
then
sleep 1
echo -n "fetchmail already running " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
else
echo -n "starting fetchmail at " >>${Mlog}/${Log}
/usr/local/bin/fetchmail --fetchmailrc /home/gene/.fetchmailrc >>${Mlog}/${Log} &
date -R >>${Mlog}/${Log}
fi
sleep 1 # delay to give kmail a chance to get its dcop/dbus sockets setup?
$cmd
while [ $(pidof -s kmail) ]
do
# I've found that stderr needs dumped to /dev/null, so
InMail=`/usr/bin/inotifywait -q -e close_write --format %f ${WatchDir}` # 2>&1 >/dev/null
# and here it sits until inotifywait exits because of an incoming mail
# and time later it will exit, setting $InMail to something, so
# recheck to make sure kmail is still about before sending the signal
# as dbus/dcop seems to get a tummy ache if there is no receiver
if test "${InMail}" = "gene"
then
$Cmd
# sleep 1
# log it
echo -n ${InMail} >>${Mlog}/${Log}
echo -n " @ " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
elif test "${InMail}" = "gene-from_linda"
then
$Cmd
# sleep 1
# log it
echo -n ${InMail} >>${Mlog}/${Log}
echo -n " @ " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
elif test "${InMail}" = "amanda"
then
$Cmd
# sleep 1
# log it
echo -n ${InMail} >>${Mlog}/${Log}
echo -n " @ " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
fi
done
# we don't have a pidof kmail, log that its gone
echo -n "Kmails pid is missing - it has stopped ">>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
# Now, kill fetchmail too, and this is ok to do
killall fetchmail
# get rid of a waiting inotifywait, but this is not inotifywait instance
# sensitive and may kill the one for cocoprint.
killall inotifywait
fi
# and should be back in the outer loop, waiting for a kmail PID
done
but... its Apparentely not getting the dbus msg to kmail. and to me its magic so what do I check next?
dbus is running:
root@coyote:/home/gene# ps -ea|grep dbus
696 ? 00:01:11 dbus-daemon
1768 ? 00:00:02 dbus-daemon
1975 ? 00:00:01 dbus-daemon
2955 pts/0 00:00:00 dbus-launch
2956 ? 00:00:00 dbus-daemon
13857 ? 00:00:00 dbus
13868 ? 00:00:00 dbus
thank you Steven, gene
no, it works fine with no reported errors.
And I just found kmail-1.9, hidden away in /opt, and it sees all my old mail!
So, rescue all my old scripts and see if I can get them started. Then I'll have a
real email agent again. If they will run :-/
Cheers Mike, Gene
As a normal user do "grep '^root:' /etc/passwd". Don't post the
result here. Does it end in /bin/bash or /usr/sbin/nologin
or something else?
Also if you haven't tried "sudo bash" please try that as it
is only the same as "sudo -i" if root's login shell is bash.
Which it is, /bin/bash.
Next?
Thanks Mike, Gene
