Re: tmp on tmpfs

[Nicolas George]

to...@tuxteam.de (12023-04-19):
> What I didn't like from the post is that it doesn't clearly
> state the downsides. Too much handwaving and repetition that
> "there are downsides" (well, duh), that "some applications
> rely on... " (what?). Then he goes on to explain alternatives.

“If I can't write gigabytes files, it's completely and utterly useless”
is what I managed to read.

I am not that surprised to find this level of argumentation in a text
that announces its unbalanced conclusion in the title. Like all those
“foobar considered harmful” essays: they usually blame a caricature of
the other side, they argue against the worst possible version of the
idea and thus miss the points of their proponents.

I have only a limited sympathy for the self-styled rational “community”,
but their principle of “steelmaning” the other side argument before
trying to reply is a good one.

> The upsides aren't that spectacular either. If you've enough
> RAM, file system caching is so good that tmpfs will only be
> marginally faster: The write path to the disk will be a bit
> clearer. There will be a bit less CPU usage if your /tmp would
> be otherwise on a LUKS partition (mine would).

Another minor difference that can be a minor upside or downside
depending on the use case: with a tmpfs, the files disappear when the
computer is turned off, with a real filesystem they disappear when it is
turned on.

(I do not know if Debian has provisions to format a /tmp partition with
an ephemeral encryption key on boot, like it has for the swap.)

Regards,

-- 
  Nicolas George

Re: tmp on tmpfs

[tomas]

On Wed, Apr 19, 2023 at 01:15:01PM +0700, Max Nikulin wrote:
> On 19/04/2023 11:30, to...@tuxteam.de wrote:
> > 
> > That's what I meant above with "assuming you want a tmpfs..."
> 
> Some arguments for consideration may be found in
> 
> Summary: Moving /tmp to tmpfs makes it useless
> https://lists.debian.org/debian-devel/2012/06/msg00311.html
> 
> That is linked from 
> https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK

What I didn't like from the post is that it doesn't clearly
state the downsides. Too much handwaving and repetition that
"there are downsides" (well, duh), that "some applications
rely on... " (what?). Then he goes on to explain alternatives.

There is one downside to /tmp on tmpfs: it eats RAM. You gotta
have some of it (currently I've 9G free on / and 16G RAM).
That's the only one I can read between the lines in the above
linked post. Do you see any other?

The upsides aren't that spectacular either. If you've enough
RAM, file system caching is so good that tmpfs will only be
marginally faster: The write path to the disk will be a bit
clearer. There will be a bit less CPU usage if your /tmp would
be otherwise on a LUKS partition (mine would).

With a modern (2010s!) laptop not much to write home about.

Of course, I wouldn't propose to set it as a default for a
distro.

Cheers
-- 
t


signature.asc
Description: PGP signature

tmp on tmpfs

[Max Nikulin]

On 19/04/2023 11:30, to...@tuxteam.de wrote:


That's what I meant above with "assuming you want a tmpfs..."


Some arguments for consideration may be found in

Summary: Moving /tmp to tmpfs makes it useless
https://lists.debian.org/debian-devel/2012/06/msg00311.html

That is linked from 
https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK


Or another link:
https://lwn.net/Articles/499410/
Jake Edge. Temporary files: RAM or disk? May 31, 2012

Re: /etc/fstab question (problem)?

[tomas]

On Tue, Apr 18, 2023 at 10:15:30PM +0100, Tom Furie wrote:
> On Tue, Apr 18, 2023 at 09:00:00PM +0200, to...@tuxteam.de wrote:
> > Since Debian erases /tmp at each boot anyway: wouldn't it be
> > much easier to set up an entry in fstab along the lines of
> > 
> >   tmpfs/tmptmpfsdefaults,noatime,mode=1777   0  0
> > 
> > (assuming you want a tmpfs there, replace by suitable partition,
> > options, etc)... and wait for the next reboot to pick it up?
> 
> That gives a memory backed /tmp, which, depending on resources/requirements
> may be more or less suitable, for some definition of "suitable".

That's what I meant above with "assuming you want a tmpfs..."

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: /etc/fstab question (problem)?

[Stefan Monnier]

> So—I would clean /tmp as best you can before you close down, then
> boot in single user mode, clean anything still remaining in /tmp,
> edit your fstab, and then reboot.

You can also do

mount --bind / /mnt

and then look at /mnt/tmp.
No need to reboot into single-user mode for that.


Stefan

Re: Email submission.

[David Wright]

On Sun 16 Apr 2023 at 10:57:37 (-0700), pe...@easthope.ca wrote:
> From: David Wright 
> Date: Sat, 15 Apr 2023 22:20:55 -0500
> > And in turn, this reply doesn't contain any feedback to my suggestion
> > of installing the backported exim, which claims to support tls on
> > connect.
> 
> Yes, sorry.  Too wary of venturing beyond stable.
> 
> Now installed backported exim.  Unnecessary blanks removed for
> legibility here.
> $ dpkg -l | grep exim
> ii exim4  4.96-14~bpo11+1 all   metapackage to ease Exim
> MTA (v4) installation
> ii exim4-base 4.96-14~bpo11+1 amd64 support files for all Exim
> MTA (v4) packages
> ii exim4-config   4.96-14~bpo11+1 all   configuration for the Exim
> MTA (v4)
> ii exim4-daemon-light 4.96-14~bpo11+1 amd64 lightweight Exim MTA (v4)
> daemon
> 
> No new question in "dpkg-reconfigure exim4-config".  Shouldn't it ask
> to choose between STARTTLS and TLS-on-connect?
> 
> /etc/exim4/update-exim4.conf.conf is unchanged by adding the backport.

I don't think you micromanage exim4 at that level. From browsing the
configuration file(s), I think you tell it things like Do I want
encryption, Do I want to force it, Do I want to check certificates,
or don't I care, and then it makes decisions on what the connecting
mail servers say and do.

 "Exim supports TLS-on-connect by means of the tls_on_connect_ports
  global option. Its value must be a list of port numbers; the most
  common use is expected to be:

  tls_on_connect_ports = 465

 "The port numbers specified by this option apply to all SMTP
  connections, both via the daemon and via inetd. You still need to
  specify all the ports that the daemon uses (by setting
  daemon_smtp_ports or local_interfaces or the -oX command line option)
  because tls_on_connect_ports does not add an extra port – rather, it
  specifies different behaviour on a port that is defined elsewhere."

That's what led me to think that that line might need to be in the
Transport section of /var/lib/exim4/config.autogenerated. (Bear in
mind that reconfiguring exim4 refreshes this file, so it's a good
place to conduct ephemeral experiments.)

But I don't have enough (any) experience of this connection method to
know why the list of ports has to be limited, or even whether the
setting is aimed at outward or inward connections. Impossible for me
to test without an instance to try it out on unless, I suppose, I sent
emails back and forth between two machines. (Hey, I do that already,
but without TLS at all.)

> > My only remaining advice is to try everything on every port.
> > Frequently, one particular method is advertised, but the software
> > may allow other protocols/methods too. For example, the SMTP
> > port and commands that mutt sends my posts with is quite different
> > from those used by my hand-crafted automated emails (same hosts).
> 
> Certainly trying many combinations.  Technical support from the
> smarthost
> also might recogize a detail I'm overlooking.

I don't know who runs it and how supportive they are. Mine tend
to be quite helpful.

> > I don't recall ever seeing a debug message with a heading.
> 
> Not a heading for the file or a comment explaining one line.
> Headings for more abstract levels of progress.
> Eg.
> "Evaluating whether delivery is local."
> "Submitting password for user  to smarthost ."

There are debug options outlined in the man page, which you can
apply through /etc/default/exim4. Presumably, tls and transport
might give interesting information.

> Incidentally the debug text has formal syntax such as this.
> 08:29:51  3623}{${if def:sender_ident {from
> ${quote_local_part:$sender_ident} }}${if def:sender_helo_name
> {(helo=$sender_helo_name)
> Does anyone recognize a language?  Exim internal syntax?

IDK. With things like this, I just program by example.

Cheers,
David.

Re: /etc/fstab question (problem)?

[David Wright]

On Tue 18 Apr 2023 at 21:12:33 (-0400), Default User wrote:
> 
> (Not so) fun fact: Clonezilla always refuses to back up swap
> partitions. I don't know why.

It's not clear to me how you could restore the entire rest of the
system to the state it was in when you made your backup of swap.
So the backup copy becomes instantly useless except for forensics
or theft, ie scanning for fragments of text, passwords etc.
That's why I encrypt my swap partitions with a random key.

> Several different approaches to solve the problem have been suggested. 
> I think I will wait until tomorrow and ponder the options, before
> performing "surgery".

If you're prepared to reboot, it should be straightforward, but there
is one factor I haven't seen mentioned, and that's to do with cleaning.

If you add the "lost line" back into fstab:
  UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2
then when the system starts up, partition 5 will be mounted onto
/tmp in the root filesystem, and then it'll be cleaned of any files
left over from the last time it was used. It might be a long, long
time since you used it so there could conceivably be files that you
want to check out.

So, I would mount partition 5 on /mnt and look it over. Yes, you've
backed up the partition, but you might never look at that, whereas
this is something you can do straightaway.

That aspect was already mentioned by DbB. But there is one further
point to make. AIUI, cleaning will be carried out on /tmp after the
partition (5) has been mounted. It wouldn't make sense otherwise.
But look at your usage of /tmp now—that is, the /tmp in the root
partition. If it contains some large files when you shut down in
preparation to change fstab, then those files, sitting on /, will
never get cleaned. They'll be hidden by mounting partition 5 on
top of them, and use disk space for ever.

So—I would clean /tmp as best you can before you close down, then
boot in single user mode, clean anything still remaining in /tmp,
edit your fstab, and then reboot.

> Finally, after the current situation is resolved, I would still like to
> know what caused the problem in the first place. I would really like to
> not have it happen again!

It looks as if someone edited the entries with tabs to make it line up
neatly, removed the installers comments, and accidentally removed the
/tmp line too. I don't know of any software that would do that to fstab.

Cheers,
David.

Re: /etc/fstab question (problem)?

[David Christensen]

On 4/18/23 18:12, Default User wrote:


On 4/18/23 07:59, Default User wrote:



I just realized that my /tmp partition is not being mounted at
startup.



Finally, after the current situation is resolved, I would still like to
know what caused the problem in the first place.



Looking back at previous posts:


On 4/18/23 07:59, Default User wrote:

> Current /etc/fstab:
> #  
>
> UUID=4fdd4399-6267-404a-a292-
> cdc7761df3c9   /   ext4errors=remount-ro   0   1
> UUID=26EE-0EF5 /boot/efi   vfatumask=0077  0   1
> UUID=00f0c2db-0490-4354-b949-
> f9af11a7f001   /home   ext4defaults0   2
> UUID=8bfeee23-9c09-45b7-a73e-
> bd2ff43e207c   /varext4defaults0   2
> UUID=e2a56ec3-99d4-4b40-9aa4-
> 24975143cdc7   noneswapsw  0   0

> Original /etc/fstab:

> # /tmp was on /dev/nvme0n1p5 during installation
> UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmpext4
> defaults0   2


It appears that the fstab(5) entry for /etc was dropped when:

On 4/18/23 14:42, Default User wrote:

> My best guess is that I may have done a system restore
> using Timeshift on 2023-04-03, to back out of some unremembered
> problem, and the current /etc/fstab results from that.


I would try adding the fstab(5) entry for /tmp from the original 
/etc/fstab to the current /etc/fstab, and then rebooting.



(If this works, the contents of the /tmp directory of the root file 
system will be overlaid by the /tmp file system.  To reclaim space on 
the root file system, I would boot the system using a live drive or the 
d-i rescue shell, mount the root file system at /mnt, and then remove 
the contents of /mnt/tmp.  Note that you do not want to remove the 
/mnt/tmp directory, because it is the mount point for the /tmp file system.)



David

Re: /etc/fstab question (problem)?

[Charles Curley]

On Tue, 18 Apr 2023 21:12:33 -0400
Default User  wrote:

> (Not so) fun fact: Clonezilla always refuses to back up swap
> partitions. I don't know why.

Because there is no reason to do so. It has nothing in it of any value,
except possibly to a cracker, and even that is stale.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: /etc/fstab question (problem)?

[Default User]

On Tue, 2023-04-18 at 16:53 -0700, David Christensen wrote:
> On 4/18/23 14:42, Default User wrote:
> > On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote:
> > > On 4/18/23 07:59, Default User wrote:
> > > > Hey, I have a strange situation!
> > > > 
> > > > I just realized that my /tmp partition is not being mounted at
> > > > startup.
> > > > Instead, I think the filesystem may be allocating space in
> > > > another
> > > > partition (maybe /root?) for tmp stuff.
> 
> > > My / (root) and /tmp directories are on the same file system --
> > > the
> > > root
> > > filesystem:
> > > 
> > > 2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com
> > > # stat -c %d / /tmp
> > > 65024
> > > 65024
> 
> > stat -c %d / /tmp
> > 66306
> > 66306
> > (I am not sure what that means - is that saying that /tmp is
> > mounted
> > under / on the / partition?)
> 
> 
> stat(1) is saying that the file system entries "/" and "/tmp" have
> the 
> same "device number".  Device numbers should be unique for the
> various 
> file systems that are mounted on one computer:
> 
> # mount | perl -ane '$_=$F[2];$dev=(stat)[0];print"$dev $_\n"' | sort
> -n
>   /run/user/13250/doc
> 5 /dev
> 6 /sys/kernel/security
> 7 /sys/kernel/debug
> 11 /sys/kernel/tracing
> 19 /dev/mqueue
> 20 /sys
> 21 /proc
> 22 /dev/pts
> 23 /run
> 26 /dev/shm
> 27 /run/lock
> 28 /sys/fs/cgroup
> 29 /sys/fs/pstore
> 30 /sys/firmware/efi/efivars
> 31 /sys/fs/bpf
> 32 /proc/sys/fs/binfmt_misc
> 33 /dev/hugepages
> 34 /sys/fs/fuse/connections
> 35 /sys/kernel/config
> 39 /samba/dpchrist
> 40 /samba/groupshare
> 42 /run/user/13250
> 50 /run/user/0
> 2049 /boot/efi
> 2050 /boot
> 65024 /
> 65026 /scratch
> 
> 
> That said, I think I prefer the df(1) solution posted by Greg
> Wooledge.
> 
> 
> > (And BTW, the current /etc/fstab must have been written by some
> > program, not manually by me.  I would never have edited /etc/fstab
> > to
> > look like that!) My best guess is that I may have done a system
> > restore
> > using Timeshift on 2023-04-03, to back out of some unremembered
> > problem, and the current /etc/fstab results from that.
> 
> 
> Backing up system configuration files is good.
> 
> 
> I use a version control system (CVS), create a project for each host,
> and check in every system configuration file I create, update, or 
> delete.  I also keep a log.txt file for each system, write notes to 
> myself, save console sessions, etc., for when I do need to remember
> what 
> I did, when, and why.  Rather than restoring entire system
> configuration 
> files, I typically use an editor and restore specific settings.
> 
> 
> > I COULD just continue as is with the current setup, but I would
> > REALLY
> > prefer not to!
> 
> 
> Why not?
> 
> 
> > Maybe I should just start by using Clonezilla to do a full image of
> > the
> > drive. Actual data of course, not the entire 256 Gb!
> 
> 
> Putting your data on a different device than your OS allows you to 
> optimize device usage and backup, restore, archive, imaging, etc., 
> procedures.
> 
> 
> > More later . . .
> 
> 
> David
> 

I have made 2 backups of the ssd, using Clonezilla.
1) a full disk backup,from which the whole disk can be restored.
2) a partitions backup, from which any or all of the individual
partitions can be restored.
Both have been checked by Clonezilla to be restorable.

(Not so) fun fact: Clonezilla always refuses to back up swap
partitions. I don't know why.

FWIW:
df /tmp
Filesystem 1K-blocksUsed Available Use% Mounted on
/dev/nvme0n1p2  23854928 5841496  16776340  26% /

Several different approaches to solve the problem have been suggested. 
I think I will wait until tomorrow and ponder the options, before
performing "surgery".

Note: It was asked why I don't just use the current setup, with no 
/tmp partition.  I guess it goes back to years ago, when I used OpenBSD
for a while. They really pushed the idea of having at least /, /tmp,
/var, swap, and /home partitions. I think the idea is that if something
happens to one partition, it won't affect the others. Like if a process
unexpectedly fills up one partition (/tmp /var, etc.) it probably won't
send the whole system crashing down.

Finally, after the current situation is resolved, I would still like to
know what caused the problem in the first place. I would really like to
not have it happen again!

Re: /etc/fstab question (problem)?

[David Christensen]

On 4/18/23 14:42, Default User wrote:

On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote:

On 4/18/23 07:59, Default User wrote:

Hey, I have a strange situation!

I just realized that my /tmp partition is not being mounted at
startup.
Instead, I think the filesystem may be allocating space in another
partition (maybe /root?) for tmp stuff.



My / (root) and /tmp directories are on the same file system -- the
root
filesystem:

2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com
# stat -c %d / /tmp
65024
65024



stat -c %d / /tmp
66306
66306
(I am not sure what that means - is that saying that /tmp is mounted
under / on the / partition?)



stat(1) is saying that the file system entries "/" and "/tmp" have the 
same "device number".  Device numbers should be unique for the various 
file systems that are mounted on one computer:


# mount | perl -ane '$_=$F[2];$dev=(stat)[0];print"$dev $_\n"' | sort -n
 /run/user/13250/doc
5 /dev
6 /sys/kernel/security
7 /sys/kernel/debug
11 /sys/kernel/tracing
19 /dev/mqueue
20 /sys
21 /proc
22 /dev/pts
23 /run
26 /dev/shm
27 /run/lock
28 /sys/fs/cgroup
29 /sys/fs/pstore
30 /sys/firmware/efi/efivars
31 /sys/fs/bpf
32 /proc/sys/fs/binfmt_misc
33 /dev/hugepages
34 /sys/fs/fuse/connections
35 /sys/kernel/config
39 /samba/dpchrist
40 /samba/groupshare
42 /run/user/13250
50 /run/user/0
2049 /boot/efi
2050 /boot
65024 /
65026 /scratch


That said, I think I prefer the df(1) solution posted by Greg Wooledge.



(And BTW, the current /etc/fstab must have been written by some
program, not manually by me.  I would never have edited /etc/fstab to
look like that!) My best guess is that I may have done a system restore
using Timeshift on 2023-04-03, to back out of some unremembered
problem, and the current /etc/fstab results from that.



Backing up system configuration files is good.


I use a version control system (CVS), create a project for each host, 
and check in every system configuration file I create, update, or 
delete.  I also keep a log.txt file for each system, write notes to 
myself, save console sessions, etc., for when I do need to remember what 
I did, when, and why.  Rather than restoring entire system configuration 
files, I typically use an editor and restore specific settings.




I COULD just continue as is with the current setup, but I would REALLY
prefer not to!



Why not?



Maybe I should just start by using Clonezilla to do a full image of the
drive. Actual data of course, not the entire 256 Gb!



Putting your data on a different device than your OS allows you to 
optimize device usage and backup, restore, archive, imaging, etc., 
procedures.




More later . . .



David

Re: /etc/fstab question (problem)?

[Greg Wooledge]

On Tue, Apr 18, 2023 at 05:42:52PM -0400, Default User wrote:
> stat -c %d / /tmp
> 66306
> 66306
> (I am not sure what that means - is that saying that /tmp is mounted
> under / on the / partition?)

Yes.  And by the way, "df /tmp" is a much more intuitive way to get
that same answer.

unicorn:~$ df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda7   23854928 20508268   2109568  91% /

On my system, just like yours, /tmp is simply a plain ol' directory in
the root file system.

Re: /etc/fstab question (problem)?

[Default User]

On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote:
> On 4/18/23 07:59, Default User wrote:
> > Hey, I have a strange situation!
> > 
> > I just realized that my /tmp partition is not being mounted at
> > startup.
> > Instead, I think the filesystem may be allocating space in another
> > partition (maybe /root?) for tmp stuff.
> > 
> > I would like to return to the prior setup, where the /tmp partition
> > is
> > mounted at startup, and is used for the tmp stuff.
> > 
> > Can I do so without trashing my system, and having to reinstall
> > from
> > scratch.
> > 
> > Note: I have current system bakups using Timeshift, and current
> > data
> > (/home/[user]) backups using Borgbackup.
> > 
> > And I can image the ssd with Clonezilla, or even dd, if I have to.
> > But
> > I would prefer not to go through the hassle of doing so, if it is
> > not
> > really needed.
> > 
> > I am running Debian 11 Stable (Bullseye).
> > My computer has a single internal 256 Gb ssd.
> > I am using Gnome Version 3.38.5 as my desktop environment.
> > 
> > uname -a:
> > Linux [host name] 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC
> > Debian
> > 6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux
> > 
> > mount:
> > sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> > proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> > udev on /dev type devtmpfs
> > (rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64
> > )
> > devpts on /dev/pts type devpts
> > (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> > tmpfs on /run type tmpfs
> > (rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64)
> > /dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)
> > securityfs on /sys/kernel/security type securityfs
> > (rw,nosuid,nodev,noexec,relatime)
> > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
> > tmpfs on /run/lock type tmpfs
> > (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
> > cgroup2 on /sys/fs/cgroup type cgroup2
> > (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
> > pstore on /sys/fs/pstore type pstore
> > (rw,nosuid,nodev,noexec,relatime)
> > efivarfs on /sys/firmware/efi/efivars type efivarfs
> > (rw,nosuid,nodev,noexec,relatime)
> > bpf on /sys/fs/bpf type bpf
> > (rw,nosuid,nodev,noexec,relatime,mode=700)
> > systemd-1 on /proc/sys/fs/binfmt_misc type autofs
> > (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pi
> > pe_i
> > no=786)
> > hugetlbfs on /dev/hugepages type hugetlbfs
> > (rw,relatime,pagesize=2M)
> > mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
> > debugfs on /sys/kernel/debug type debugfs
> > (rw,nosuid,nodev,noexec,relatime)
> > tracefs on /sys/kernel/tracing type tracefs
> > (rw,nosuid,nodev,noexec,relatime)
> > configfs on /sys/kernel/config type configfs
> > (rw,nosuid,nodev,noexec,relatime)
> > fusectl on /sys/fs/fuse/connections type fusectl
> > (rw,nosuid,nodev,noexec,relatime)
> > /dev/nvme0n1p3 on /var type ext4 (rw,relatime)
> > /dev/nvme0n1p6 on /home type ext4 (rw,relatime)
> > /dev/nvme0n1p1 on /boot/efi type vfat
> > (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,sho
> > rtna
> > me=mixed,utf8,errors=remount-ro)
> > tmpfs on /run/user/1000 type tmpfs
> > (rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,ui
> > d=10
> > 00,gid=1000,inode64)
> > gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
> > (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> > portal on /run/user/1000/doc type fuse.portal
> > (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> > 
> > Current /etc/fstab:
> > #  
> > 
> > UUID=4fdd4399-6267-404a-a292-
> > cdc7761df3c9/   ext4errors=remount-ro   0   1
> > UUID=26EE-0EF5  /boot/efi   vfatumask=0077  0   1
> > UUID=00f0c2db-0490-4354-b949-
> > f9af11a7f001/home   ext4defaults0   2
> > UUID=8bfeee23-9c09-45b7-a73e-
> > bd2ff43e207c/varext4defaults0   2
> > UUID=e2a56ec3-99d4-4b40-9aa4-
> > 24975143cdc7noneswapsw  0   0
> > 
> > Original /etc/fstab:
> > # /etc/fstab: static file system information.
> > #
> > # Use 'blkid' to print the universally unique identifier for a
> > # device; this may be used with UUID= as a more robust way to name
> > devices
> > # that works even if disks are added and removed. See fstab(5).
> > #
> > # systemd generates mount units based on this file, see
> > systemd.mount(5).
> > # Please run 'systemctl daemon-reload' after making changes here.
> > #
> > #           
> > 
> > # / was on /dev/nvme0n1p2 during installation
> > UUID=4fdd4399-6267-404a-a292-cdc7761df3c9 /   ext4
> > errors=remount-ro 0   1
> > # /boot/efi was on /dev/nvme0n1p1 during installation
> > UUID=26EE-0EF5  /boot/efi   vfat    umask=0077  0   1
> > # /home was on /dev/nvme0n1p6 during installation
> > UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home   ext4
> > defaults    0  

Re: /etc/fstab question (problem)?

[Tom Furie]

On Tue, Apr 18, 2023 at 09:00:00PM +0200, to...@tuxteam.de wrote:
> Since Debian erases /tmp at each boot anyway: wouldn't it be
> much easier to set up an entry in fstab along the lines of
> 
>   tmpfs/tmptmpfsdefaults,noatime,mode=1777   0  0
> 
> (assuming you want a tmpfs there, replace by suitable partition,
> options, etc)... and wait for the next reboot to pick it up?

That gives a memory backed /tmp, which, depending on resources/requirements
may be more or less suitable, for some definition of "suitable".

Cheers,
Tom

-- 
We are now enjoying total mutual interaction in an imaginary hot tub ...


signature.asc
Description: PGP signature

Re: /etc/fstab question (problem)?

[David Christensen]

On 4/18/23 07:59, Default User wrote:

Hey, I have a strange situation!

I just realized that my /tmp partition is not being mounted at startup.
Instead, I think the filesystem may be allocating space in another
partition (maybe /root?) for tmp stuff.

I would like to return to the prior setup, where the /tmp partition is
mounted at startup, and is used for the tmp stuff.

Can I do so without trashing my system, and having to reinstall from
scratch.

Note: I have current system bakups using Timeshift, and current data
(/home/[user]) backups using Borgbackup.

And I can image the ssd with Clonezilla, or even dd, if I have to. But
I would prefer not to go through the hassle of doing so, if it is not
really needed.

I am running Debian 11 Stable (Bullseye).
My computer has a single internal 256 Gb ssd.
I am using Gnome Version 3.38.5 as my desktop environment.

uname -a:
Linux [host name] 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux

mount:
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs
(rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64)
/dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_i
no=786)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs
(rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs
(rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs
(rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl
(rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p3 on /var type ext4 (rw,relatime)
/dev/nvme0n1p6 on /home type ext4 (rw,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortna
me=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,uid=10
00,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Current /etc/fstab:
#  

UUID=4fdd4399-6267-404a-a292-
cdc7761df3c9/   ext4errors=remount-ro   0   1
UUID=26EE-0EF5  /boot/efi   vfatumask=0077  0   1
UUID=00f0c2db-0490-4354-b949-
f9af11a7f001/home   ext4defaults0   2
UUID=8bfeee23-9c09-45b7-a73e-
bd2ff43e207c/varext4defaults0   2
UUID=e2a56ec3-99d4-4b40-9aa4-
24975143cdc7noneswapsw  0   0

Original /etc/fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name
devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see
systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
#
# / was on /dev/nvme0n1p2 during installation
UUID=4fdd4399-6267-404a-a292-cdc7761df3c9 /   ext4
errors=remount-ro 0   1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=26EE-0EF5  /boot/efi   vfatumask=0077  0   1
# /home was on /dev/nvme0n1p6 during installation
UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home   ext4
defaults0   2
# /tmp was on /dev/nvme0n1p5 during installation
UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmpext4
defaults0   2
# /var was on /dev/nvme0n1p3 during installation
UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /varext4
defaults0   2
# swap was on /dev/nvme0n1p4 during installation
UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 noneswapsw
0   0

ls -lahFi /etc/fstab:
522243 -rw-r--r-- 1 root root 368 Apr  3 17:01 /etc/fstab

ls -lahFi /etc/fstab.original:
522547 -rw-r--r-- 1 root root 1.

Re: Am I infected with a rootkit?

[David Christensen]

On 4/18/23 06:43, Jesper Dybdal wrote:

On 2023-04-16 14:19, I wrote:

...
And there in the bash history were 4 lines that I had not written :-(


To summarize:

* Greg has convincingly argued that there is no way for the running 
shell to get those lines into its history, other than by issuing them 
over the ssh connection.


* We can therefore assume that the problem originated at the Windows 
machine (the ssh client).


* It seems that an intruder has had control over the Windows machine, 
including the ssh session, and thus, at least in principle, could have 
done harm also to the Linux machine.


* There is, however, no sign of an infection of the Linux machine. And 
the 4 lines do not suggest that whoever issued them knows what he's doing.


* So I am going to assume that the Linux machine is ok.

* The Windows machine could be infected with something that allows 
remote control.


* So I should probably reinstall the Windows machine from scratch - or 
perhaps restore a really old backup (I have one from July 2022, one from 
2020, and one taken shortly after the original install in 2016).


Many thanks to everybody who answered!
Jesper



I do not believe the analysis is complete -- I never saw an answer to 
the following question (?); it is important:


On 4/17/23 21:42, David Wright wrote:
> OK, you wrote that you "pressed up-arrow a few times. And there in the
> bash history were 4 lines …". If those 4 lines were not the first
> things to appear when you pressed up-arrow, then I would assume that
> the commands you typed/just/  before you went out with the dog were
> the first lines to appear, and then your 4 lines after more up-arrows.
>
> If that's the case, then your 4 lines could have been typed
> in a previous login as root, and that could have been some time
> ago. They would have been languishing at the end of the file
> /root/.bash_history before you logged in as root this time.


Where the four commands in questions the very last commands entered into 
Putty, or were they prior?  If the latter, how far back?  Same session? 
Same day?  A day ago?  Week?  Month?



David

Re: /etc/fstab question (problem)?

[tomas]

On Tue, Apr 18, 2023 at 09:37:51AM -0600, Charles Curley wrote:
> On Tue, 18 Apr 2023 10:59:19 -0400
> Default User  wrote:
> 
> > What to do?
> 
> I suspect that what you need to do is:
> 
> 1) Preserve the current contents of /tmp,
> 
> 2) Adjust fstab to include the /tmp partition,
> 
> 3) Mount the /tmp partition
> 
> 4) Restore the contents of /tmp

Since Debian erases /tmp at each boot anyway: wouldn't it be
much easier to set up an entry in fstab along the lines of

  tmpfs/tmptmpfsdefaults,noatime,mode=1777   0  0

(assuming you want a tmpfs there, replace by suitable partition,
options, etc)... and wait for the next reboot to pick it up?

No need to preserve anything, then.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Need help to install gnucobol

[Timothy M Butterworth]

On Tue, Apr 18, 2023 at 2:55 PM Jerry Mellon  wrote:

> Hi,
>
> I am new to Debian and I would like to install gnucobol. I see it is in
> Debian 10 but not 11. I tried to download the Debian 10 gnucobol, but I
> get a message that the package is broken. Could you tell me where else I
> might obtain a compatible cobol compiler?
>

GNUCobol is packaged in Debian 12 Bookworm:

gnucobol/testing 5 amd64
 compiler package for default GnuCOBOL

gnucobol3/testing 3.1.2-5+b1 amd64
 COBOL compiler

gnucobol4/testing 4.0~early~20200606-6+b1 amd64
 COBOL compiler

Tim


> --
> Jerry Mellon
> 501 Los Caminos St.
> St Augustine, FL 32095
> 407.461.9216
> jfmel...@netscape.net
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Need help to install gnucobol

[Jerry Mellon]

Hi,

I am new to Debian and I would like to install gnucobol. I see it is in 
Debian 10 but not 11. I tried to download the Debian 10 gnucobol, but I 
get a message that the package is broken. Could you tell me where else I 
might obtain a compatible cobol compiler?


--
Jerry Mellon
501 Los Caminos St.
St Augustine, FL 32095
407.461.9216
jfmel...@netscape.net

Re: Am I infected with a rootkit?

[Andy Smith]

Hello,

On Tue, Apr 18, 2023 at 06:22:16PM +0200, Michel Verdier wrote:
> I recently learned the ctrl-r key which launch a regex search in
> history. It's more powerful than ! as it search the full
> lines so not only commands but also parameters.

Now step in to the late 2010s and look into "fzf" 😀

(It is packaged in Debian)

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Apt sources.list

[Jeffrey Walton]

On Tue, Apr 18, 2023 at 1:46 PM Frank  wrote:
>
> Op 18-04-2023 om 16:33 schreef Vincent Lefevre:
> > On 2023-04-15 21:59:19 +0200, Frank wrote:
> >> Op 15-04-2023 om 18:12 schreef Tixy:
> >>> Testing doesn't get explicit security support so there's no point in
> >>> having 'testing-security' lines in sources.list (I guess it'll give an
> >>> error anyway).
> >>
> >> No error. It exists but as a perpetually empty repository.
> >
> > This is incorrect.
> >
> > cventin:~> apt-show-versions -a libtpms-dev
> > libtpms-dev:amd64 0.9.2-3.1~deb12u1 testing-security security.debian.org
> > No stable version
> > No stable-updates version
> > libtpms-dev:amd64 0.9.2-3.1 testing  ftp.debian.org
> > libtpms-dev:amd64 0.9.2-3.1 unstable ftp.debian.org
> > No experimental version
> > libtpms-dev:amd64 not installed
> > libtpms-dev:i386 0.9.2-3.1~deb12u1 testing-security security.debian.org
> > No stable version
> > No stable-updates version
> > libtpms-dev:i386 0.9.2-3.1 testing  ftp.debian.org
> > libtpms-dev:i386 0.9.2-3.1 unstable ftp.debian.org
> > No experimental version
> > libtpms-dev:i386 not installed
>
> Interesting. Like Tixy, I was under the impression testing didn't
> receive security support. I remember checking that several times over
> the years. Curious.

I did not think so, either. But have a look at
https://www.debian.org/security/faq#testing and
https://wiki.debian.org/DebianTesting .

Jeff

Re: Apt sources.list

[Frank]

Op 18-04-2023 om 16:33 schreef Vincent Lefevre:

On 2023-04-15 21:59:19 +0200, Frank wrote:

Op 15-04-2023 om 18:12 schreef Tixy:

Testing doesn't get explicit security support so there's no point in
having 'testing-security' lines in sources.list (I guess it'll give an
error anyway).


No error. It exists but as a perpetually empty repository.


This is incorrect.

cventin:~> apt-show-versions -a libtpms-dev
libtpms-dev:amd64 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:amd64 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:amd64 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:amd64 not installed
libtpms-dev:i386 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:i386 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:i386 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:i386 not installed


Interesting. Like Tixy, I was under the impression testing didn't 
receive security support. I remember checking that several times over 
the years. Curious.


Regards,
Frank

Re: "Bug" in Debian Installer?

[Roy J. Tellason, Sr.]

On Tuesday 18 April 2023 12:47:44 am David Wright wrote:
> > I have never seen a document that completely and accurately explains,
> > in computer engineering and science terms, the design and
> > implementation of the boot processes for Debian (or FreeBSD, or
> > Windows, or macOS) for all the possible combinations of BIOS, UEFI,
> > MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
> > Boot Partition", etc..  If anyone knows of such, please provide a
> > citation.
> 
> You might start with:
> 
>   https://www.rodsbooks.com/gdisk/whatsgpt.html
> 

Thanks for that...

It's clarified some things that I've been wondering about.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Disable laptop suspend and hibernate when plugged-in or charging?

[Jeffrey Walton]

Hi Everyone,

I have a Pinebook Pro, https://www.pine64.org/pinebook-pro/ . The
laptop suspends or hibernates even when charging. I cannot SSH into
it.

I want to disable suspend or hibernate while the laptop is plugged-in.
I visited https://wiki.debian.org/Suspend , but it does not discuss
the laptop being plugged into the power cord or charging.

(I make a small distinction between "plugged-in" and "charging." The
laptop may be fully charged and plugged-in, but it may not be charging
since it is fully charged).

How do I disable suspend or hibernate when the laptop is plugged into
the power cord or charging?

Thanks in advance.

Re: /etc/fstab question (problem)?

[Max Nikulin]

On 18/04/2023 22:37, Charles Curley wrote:

1) Preserve the current contents of /tmp,
2) Adjust fstab to include the /tmp partition,
3) Mount the /tmp partition
4) Restore the contents of /tmp


Some issues may arise due to files (regular ones, already deleted, 
sockets, fifos) opened by running services. /tmp is specific in the 
sense that no files are assumed to survive after reboot. I think, it is 
better to add the entry for tmp to /etc/fstab and to reboot.


As a final step / may be bind mounted to some other directory to remove 
remaining files (to avoid wasting of disk space) or to move them to new 
location if you do something special, so it is necessary to keep some 
files in /tmp.

Re: Am I infected with a rootkit?

[Michel Verdier]

Le 18 avril 2023 songbird a écrit :

>   i like to start with a known state including the shell history
> so upon starting up a terminal i determine what commands i want
> in the history by detecting which directory i'm in (which tells
> me which project i'm working on).  it's very easy then for me
> to start things by using the ! or !.

I recently learned the ctrl-r key which launch a regex search in
history. It's more powerful than ! as it search the full
lines so not only commands but also parameters.

Re: Am I infected with a rootkit?

[songbird]

 wrote:
...
> Definitely. I just pointed that out as a request for discussion.
> Perhaps this isn't portable across shells or even different
> versions of bash. So caveat emptor :)
>
> Cheers and thanks -- I didn't know about HISTTIMEFORMAT before!

  just as an aside for those who think about this sort of thing.  :)

  i like to start with a known state including the shell history
so upon starting up a terminal i determine what commands i want
in the history by detecting which directory i'm in (which tells
me which project i'm working on).  it's very easy then for me
to start things by using the ! or !.

  i also do not like history stuff hanging around so i may 
attempt to clear things out upon logging out or shutting down
but since some crashes can happen i do not rely upon that 
being 100%.  which is why when i do start up i set things up
how i like and do clear the history at that point (before
putting the commands in i want).


  songbird

Re: /etc/fstab question (problem)?

[songbird]

Default User wrote:
...
> What to do?

  if the tmp partition exists then put it back in your
fstab and see if you can mount it manually.  it may or
may not mount.  if it doesn't you can reboot and it
should then mount.

  of course,  make sure you have the mount point defined.


> And if further information is needed, please let me know, and I will
> try to get it for you.
>
> Thanks!


  songbird

Re: /etc/fstab question (problem)?

[Charles Curley]

On Tue, 18 Apr 2023 10:59:19 -0400
Default User  wrote:

> What to do?

I suspect that what you need to do is:

1) Preserve the current contents of /tmp,

2) Adjust fstab to include the /tmp partition,

3) Mount the /tmp partition

4) Restore the contents of /tmp

You should probably do all of this in single user mode so you don't
have other processes changing things while you're doing this. In
multi-user mode, a process might have a tmp file open, which could
also cause problems.

All of this assumes that the backup from step 1 will fit onto the /tmp
partition. Otherwise you may have to do some manual trimming.

1) Use tar or equivalent to preserve the current contents of /tmp. Then
delete the contents of /tmp. Your Timeshift backups might be recent
enough; check that they include everything currently in /tmp.

2) Copy the lines for /tmp from fstab.original to fstab. Ensure that
the UUIDs are correct, and that you are specifying the partition you
want. Check to see if you are missing any other partitions while you
are at it.

3) Mount the /tmp partition. You will likely find that there are old
files in the partition. You can probably delete them, but the more
paranoid types will preserve them first.

4) Restore the contents of /tmp from the backup you made in step 1.

Good luck!

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

/etc/fstab question (problem)?

[DdB]

Am 18.04.2023 um 16:59 schrieb Default User:
> Hey, I have a strange situation! 
Wow! Am I misunderstanding something?
You seem to be well in control of your system, thus i am i bit surprised
as of the simplicity of your question.
If it was me, i would just find out, where exactly tmp resides now, then
shutdown and boot from an ISO in order to have a "cold" system on disk.
Then mount both tmp places to check, if there is anything worth
keeping/consolidating. Otherwise clear the mountpoint and uncomment the
/tmp line from your fstab. Rebooting should then just mount it as you want.

Questions, i could not answer:
What if you wanted to make the change without downtime?
What if you want to make use of systemd services to mount /tmp?
* I assume, that one gets created automatically, if a tmpfs is used for
/tmp, but i dont know, when exactly, it would run.
Is there any relevance? I guess not.




-- 

Liebe ist ...
Datakanja

AW: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[Schwibinger Michael]

Good afternoon
How do I do driverless printing?

Thank You
Regards
Sophie



Von: Stefan Monnier 
Gesendet: Freitag, 14. April 2023 22:33
An: debian-user@lists.debian.org 
Betreff: Re: EPSON ET M 1120 new printer: If You can read this, you are using 
the wrong driver

>> The new printer is not  working.
>> EPSON is saying
>> You cant use EPSON with Linux.
>>
>> Is this true?
>
> You could consider:
>
>   * Stating the Debain OS being used.
>   * Giving the printer make and model.

"Subject:" says "EPSON ET M 1120"
AFAICT it's a monochrome printer from 2019 with some kind of ink tank.
Given the timescale, it probably supports driverless printing.


Stefan

/etc/fstab question (problem)?

[Default User]

Hey, I have a strange situation! 

I just realized that my /tmp partition is not being mounted at startup.
Instead, I think the filesystem may be allocating space in another
partition (maybe /root?) for tmp stuff. 

I would like to return to the prior setup, where the /tmp partition is
mounted at startup, and is used for the tmp stuff. 

Can I do so without trashing my system, and having to reinstall from
scratch.

Note: I have current system bakups using Timeshift, and current data
(/home/[user]) backups using Borgbackup. 

And I can image the ssd with Clonezilla, or even dd, if I have to. But
I would prefer not to go through the hassle of doing so, if it is not
really needed.

I am running Debian 11 Stable (Bullseye).
My computer has a single internal 256 Gb ssd.
I am using Gnome Version 3.38.5 as my desktop environment.

uname -a:
Linux [host name] 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux

mount:
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs
(rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64)
/dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_i
no=786)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs
(rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs
(rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs
(rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl
(rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p3 on /var type ext4 (rw,relatime)
/dev/nvme0n1p6 on /home type ext4 (rw,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortna
me=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,uid=10
00,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Current /etc/fstab:
#  

UUID=4fdd4399-6267-404a-a292-
cdc7761df3c9/   ext4errors=remount-ro   0   1
UUID=26EE-0EF5  /boot/efi   vfatumask=0077  0   1
UUID=00f0c2db-0490-4354-b949-
f9af11a7f001/home   ext4defaults0   2
UUID=8bfeee23-9c09-45b7-a73e-
bd2ff43e207c/varext4defaults0   2
UUID=e2a56ec3-99d4-4b40-9aa4-
24975143cdc7noneswapsw  0   0

Original /etc/fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name
devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see
systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
#
# / was on /dev/nvme0n1p2 during installation
UUID=4fdd4399-6267-404a-a292-cdc7761df3c9 /   ext4   
errors=remount-ro 0   1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=26EE-0EF5  /boot/efi   vfatumask=0077  0   1
# /home was on /dev/nvme0n1p6 during installation
UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home   ext4   
defaults0   2
# /tmp was on /dev/nvme0n1p5 during installation
UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmpext4   
defaults0   2
# /var was on /dev/nvme0n1p3 during installation
UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /varext4   
defaults0   2
# swap was on /dev/nvme0n1p4 during installation
UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 noneswapsw  
0   0

ls -lahFi /etc/fstab:
522243 -rw-r--r-- 1 root root 368 Apr  3 17:01 /etc/fstab

ls -lahFi /etc/fstab.original:
522547 -rw-r--r-- 1 root root 1.3K Mar 11 12:02 /etc/f

Re: Am I infected with a rootkit?

[Charles Curley]

On Tue, 18 Apr 2023 22:07:16 +0800
Jeremy Ardley  wrote:

> The only way to be sure you are secure is to check the client list on 
> the router. If you have something you don't recognise then that may
> be an intruder.

You might also look into arpwatch and arpalert.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Apt sources.list

[Vincent Lefevre]

On 2023-04-15 21:59:19 +0200, Frank wrote:
> Op 15-04-2023 om 18:12 schreef Tixy:
> > On Sat, 2023-04-15 at 08:11 -0400, pa...@quillandmouse.com wrote:
> 
> > > According to https://www.debian.org/releases/, bookworm at this time is
> > > "testing". But when the next release comes, bookworm will still be
> > > bookworm, but "testing" will be bookworm "plus". I'd like to follow
> > > testing, regardless of the status of Debian official releases.
> > > 
> > > So... in my sources.list, if I change "bookworm" to "testing", will it
> > > do that, and (other than the instabilities of testing) is there any
> > > liability to it?
> > 
> > Testing doesn't get explicit security support so there's no point in
> > having 'testing-security' lines in sources.list (I guess it'll give an
> > error anyway).
> 
> No error. It exists but as a perpetually empty repository.

This is incorrect.

cventin:~> apt-show-versions -a libtpms-dev
libtpms-dev:amd64 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:amd64 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:amd64 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:amd64 not installed
libtpms-dev:i386 0.9.2-3.1~deb12u1 testing-security security.debian.org
No stable version
No stable-updates version
libtpms-dev:i386 0.9.2-3.1 testing  ftp.debian.org
libtpms-dev:i386 0.9.2-3.1 unstable ftp.debian.org
No experimental version
libtpms-dev:i386 not installed

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bookworm: dash shell globs don't recognise [^...] to negate a character class

[Greg Wooledge]

On Tue, Apr 18, 2023 at 04:19:47PM +0200, Vincent Lefevre wrote:
> BTW, history expansion can be very useful, but IMHO, this should
> have been interactive and triggered by control characters or
> escape sequences, not by "normal" characters.

History expansion originated in csh, and was duplicated in bash, which
aimed to be accomodating and familiar to both ksh/sh and csh users.

If history expansion feels foreign or alien, or if it has unexpected
interactions with other shell features... well, that's why.

Re: Bookworm: dash shell globs don't recognise [^...] to negate a character class

[Vincent Lefevre]

On 2023-04-16 11:04:09 +0700, Max Nikulin wrote:
> On 15/04/2023 19:37, Greg Wooledge wrote:
> > On Sat, Apr 15, 2023 at 11:02:12AM +, davidson wrote:
> > > On Sat, 15 Apr 2023 Max Nikulin wrote:
> > > > The problem is to prevent history expansion while keeping pattern
> > > > matching (glob) active.
> > > > 
> > > >du -ks -- .[!.]* | sort -n | tail
> > > 
> > > Are there versions of bash that exhibit history expansion in the
> > > example above?
> > 
> > Not that I've found.  I tried 3.2 and 2.05b and they're both fine.
> 
> I am really sorry. I have checked the terminal app buffer where I was
> experimenting with history expansion and almost certainly I
> misinterpreted some result.
> 
> I see that inside square brackets expansion of exclamation mark is
> suppressed when (and only when) it immediately follows the opening
> bracket.
> - [!c] is safe
> - [a-f!@1-2] and [0-9!] are affected by history expansion
>   (and it is likely the source of my confusion)

Having such an exception is very ugly. Contrary to bash, ksh93 and zsh
do not have such an exception. But since this is for interactive use,
there is usually no need for portability, so that one can use ^
instead of ! in shells that have history expansion.

BTW, history expansion can be very useful, but IMHO, this should
have been interactive and triggered by control characters or
escape sequences, not by "normal" characters.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Am I infected with a rootkit?

[Jeremy Ardley]

On 18/4/23 21:36, Jesper Dybdal wrote:



Is it secured with
wpa2?
Yes.  The password is not easy to guess, and the neighbors do not know 
it.  I think (but I may remember that incorrectly) that I checked the 
log file in the access point and found nothing suspicious.




Coincidentally I was checking on ways to break into a WiFi network today.

I should explain that for the first time yesterday I added a laptop to 
my network by pressing a button on the wireless access point. It avoids 
the need to type in my particularly long WPA2 password.


On reflection this sounded odd to me on and researching and I found 
there are no security checks. The button is pressed and for a few 
seconds any device in range can make a permanent connection without 
password.


There is a second PIN mode where an attacker can brute force an 8 digit PIN.

The final mode that I'm used to is the Private Shared Key mode where the 
user knows the WPA2 password.


The only way to be sure you are secure is to check the client list on 
the router. If you have something you don't recognise then that may be 
an intruder. However even that may not be sufficient so tools like nmap 
can locate active hosts on your wifi network. Finally, wireshark can 
monitor at the layer 2 level to identify unusual MAC addresses.



--
Jeremy
(Lists)

Re: Am I infected with a rootkit?

[Jesper Dybdal]

On 2023-04-18 10:25, Richmond wrote:

It's a long shot, but does either computer have wifi?


Those two computers do not, but the LAN they're connected to does have a 
WiFi access point.  So yes, if anybody could access the LAN through the 
WiFi and find a security hole in Windows to exploit, then that could be 
the problem.  However:



Is it secured with
wpa2?
Yes.  The password is not easy to guess, and the neighbors do not know 
it.  I think (but I may remember that incorrectly) that I checked the 
log file in the access point and found nothing suspicious.


Thanks,
Jesper

--
Jesper Dybdal
https://www.dybdal.dk

Re: Am I infected with a rootkit?

[Jesper Dybdal]

On 2023-04-18 07:29, David wrote:

On Tue, 18 Apr 2023 at 04:42, David Wright  wrote:


There is an option to timestamp entries in the history file. I've
never used it, nor heard of its being used. That might disambiguate
things if you ever suspect it might happen again.

Hi, on my machines I use Bash as interactive
shell, with:
HISTTIMEFORMAT=: %Y%m%d_%H%M%S ;

That provides a couple of benefits:

...

Thanks to David, David, Tomas, and debian-u...@howorth.org.uk for the 
suggestion of using time stamps on the history lines.  I intend to do 
that in the future.


--
Jesper Dybdal
https://www.dybdal.dk

Re: Am I infected with a rootkit?

[Jesper Dybdal]

On 2023-04-16 14:19, I wrote:

...
And there in the bash history were 4 lines that I had not written :-(


To summarize:

* Greg has convincingly argued that there is no way for the running 
shell to get those lines into its history, other than by issuing them 
over the ssh connection.


* We can therefore assume that the problem originated at the Windows 
machine (the ssh client).


* It seems that an intruder has had control over the Windows machine, 
including the ssh session, and thus, at least in principle, could have 
done harm also to the Linux machine.


* There is, however, no sign of an infection of the Linux machine. And 
the 4 lines do not suggest that whoever issued them knows what he's doing.


* So I am going to assume that the Linux machine is ok.

* The Windows machine could be infected with something that allows 
remote control.


* So I should probably reinstall the Windows machine from scratch - or 
perhaps restore a really old backup (I have one from July 2022, one from 
2020, and one taken shortly after the original install in 2016).


Many thanks to everybody who answered!
Jesper

--
Jesper Dybdal
https://www.dybdal.dk

Re: Am I infected with a rootkit?

[tomas]

On Tue, Apr 18, 2023 at 11:59:58AM +, David wrote:
> On Tue, 18 Apr 2023 at 07:51,  wrote:
> > On Tue, Apr 18, 2023 at 05:29:43AM +, David wrote:

[...]

> > > The colon and semicolon allow the timestamp
> > > to function as a no-operation command.
> >
> > At least in bash, this doesn't seem necessary, as you are
> > only seeing an external representation: internally, bash
> > keeps the timestamp separate (as happens to the seq number,
> > too).
> 
> Hi, it could well be unnecessary, I haven't played with it
> for a long time.

[...]

> It also would have been several Bash versions ago, Bash 2 or 3, so
> perhaps the behaviour changed since I configured it.
> 
> Anyway, if it isn't necessary now, there's no reason for me to advocate
> doing that, so I appreciate that you have let everyone know about that.

Definitely. I just pointed that out as a request for discussion.
Perhaps this isn't portable across shells or even different
versions of bash. So caveat emptor :)

Cheers and thanks -- I didn't know about HISTTIMEFORMAT before!

-- 
t


signature.asc
Description: PGP signature

Re: Am I infected with a rootkit?

[David]

On Tue, 18 Apr 2023 at 07:51,  wrote:
> On Tue, Apr 18, 2023 at 05:29:43AM +, David wrote:
> > On Tue, 18 Apr 2023 at 04:42, David Wright  wrote:

> > > There is an option to timestamp entries in the history file. I've
> > > never used it, nor heard of its being used. That might disambiguate
> > > things if you ever suspect it might happen again.
> >
> > Hi, on my machines I use Bash as interactive
> > shell, with:
> > HISTTIMEFORMAT=: %Y%m%d_%H%M%S ;
> >
> > That provides a couple of benefits:
> >
> > 1) it writes a commented Unix timestamp with
> > each addition to the ~/.bash_history file, so that
> > the history file not only logs what commands were
> > run interactively, but also when.
> >
> > 2) when I run the 'history' command, the outpt
> > is formatted like this:
> > 501  : 20230418_151124 ; help history
> > 502  : 20230418_151406 ; env
> > 503  : 20230418_151749 ; history
> > The colon and semicolon allow the timestamp
> > to function as a no-operation command.
>
> At least in bash, this doesn't seem necessary, as you are
> only seeing an external representation: internally, bash
> keeps the timestamp separate (as happens to the seq number,
> too).

Hi, it could well be unnecessary, I haven't played with it
for a long time.

I'm sure that there would have been some reason at the
time why I chose to configure it that way, but it is so many years
ago that I can't recall the reason.

Guessing, it could just have been that I was lazy and doing something
odd. Perhaps I wanted to dump the history output into a file, preserve
the timestamps for some long-forgotten reason, and also put a shebang
at the top of the file and run it again with minimal editing. Or maybe
I wanted a known delimiter that I could strip automatically from
the history output. I dunno.

It also would have been several Bash versions ago, Bash 2 or 3, so
perhaps the behaviour changed since I configured it.

Anyway, if it isn't necessary now, there's no reason for me to advocate
doing that, so I appreciate that you have let everyone know about that.

Re: Am I infected with a rootkit?

[tomas]

On Tue, Apr 18, 2023 at 11:51:42AM +0100, debian-u...@howorth.org.uk wrote:
>  wrote:

[...]

> > At least in bash, this doesn't seem necessary, as you are
> > only seeing an external representation: internally, bash
> > keeps the timestamp separate (as happens to the seq number,
> > too).
> > 
> > In the external file, the timestamps are kept as #-comments
> > in separate lines (with the UNIX timestamps in them).
> 
> bash seems to treat root and a normal user differently.

On my box, history, .bash_history and HISTTIMEFORMAT behave as
I described both for root and for a regular user.

Just to be sure:
# tomas@trotzki:~$ bash --version
# GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
# Copyright (C) 2020 Free Software Foundation, Inc.
# License GPLv3+: GNU GPL version 3 or later 
# 
# This is free software; you are free to change and redistribute it.
# There is NO WARRANTY, to the extent permitted by law.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Am I infected with a rootkit?

[debian-user]

 wrote:
> On Tue, Apr 18, 2023 at 05:29:43AM +, David wrote:
> > On Tue, 18 Apr 2023 at 04:42, David Wright
> >  wrote: 
> > > There is an option to timestamp entries in the history file. I've
> > > never used it, nor heard of its being used. That might
> > > disambiguate things if you ever suspect it might happen again.  
> > 
> > Hi, on my machines I use Bash as interactive
> > shell, with:
> > HISTTIMEFORMAT=: %Y%m%d_%H%M%S ;
> > 
> > That provides a couple of benefits:
> > 
> > 1) it writes a commented Unix timestamp with
> > each addition to the ~/.bash_history file, so that
> > the history file not only logs what commands were
> > run interactively, but also when.
> > 
> > 2) when I run the 'history' command, the outpt
> > is formatted like this:
> > 501  : 20230418_151124 ; help history
> > 502  : 20230418_151406 ; env
> > 503  : 20230418_151749 ; history
> > The colon and semicolon allow the timestamp
> > to function as a no-operation command.  
> 
> At least in bash, this doesn't seem necessary, as you are
> only seeing an external representation: internally, bash
> keeps the timestamp separate (as happens to the seq number,
> too).
> 
> In the external file, the timestamps are kept as #-comments
> in separate lines (with the UNIX timestamps in them).

bash seems to treat root and a normal user differently.

> > That means that history expansion
> > can still function, for example entering !502
> > interactively will run line number 502, but
> > only the 'env' that comes after the semicolon
> > will have any effect.  
> 
> I tried it out, and this also works with a "naked" timestamp,
> without the : ... ; wrapping.
> 
> Caveat: I only tried with bash.
> 
> Cheers

Re: "Bug" in Debian Installer?

[David Christensen]

On 4/17/23 21:47, David Wright wrote:

On Mon 17 Apr 2023 at 15:26:58 (-0700), David Christensen wrote:



I have never seen a document that completely and accurately explains,
in computer engineering and science terms, the design and
implementation of the boot processes for Debian (or FreeBSD, or
Windows, or macOS) for all the possible combinations of BIOS, UEFI,
MBR, and GPT; including work-arounds such as "protective MBR", "BIOS
Boot Partition", etc..  If anyone knows of such, please provide a
citation.


You might start with:

   https://www.rodsbooks.com/gdisk/whatsgpt.html



Thank you for the link.



I will expand my statement to: d-i should inform the user and obtain
their permission before making changes to a computer.


As in "Permission to break an egg, sir"? Did not pressing Enter in
reply to "Install" imply something?



d-i modifying a disk without explicit notification and permission is 
unacceptable.



d-i modifying NVRAM without explicit notification and permission is 
unacceptable.



Do you contribute to d-i?


David

Re: Am I infected with a rootkit?

[Richmond]

It's a long shot, but does either computer have wifi? Is it secured with
wpa2?

Re: Am I infected with a rootkit?

[tomas]

On Tue, Apr 18, 2023 at 05:29:43AM +, David wrote:
> On Tue, 18 Apr 2023 at 04:42, David Wright  wrote:
> 
> > There is an option to timestamp entries in the history file. I've
> > never used it, nor heard of its being used. That might disambiguate
> > things if you ever suspect it might happen again.
> 
> Hi, on my machines I use Bash as interactive
> shell, with:
> HISTTIMEFORMAT=: %Y%m%d_%H%M%S ;
> 
> That provides a couple of benefits:
> 
> 1) it writes a commented Unix timestamp with
> each addition to the ~/.bash_history file, so that
> the history file not only logs what commands were
> run interactively, but also when.
> 
> 2) when I run the 'history' command, the outpt
> is formatted like this:
> 501  : 20230418_151124 ; help history
> 502  : 20230418_151406 ; env
> 503  : 20230418_151749 ; history
> The colon and semicolon allow the timestamp
> to function as a no-operation command.

At least in bash, this doesn't seem necessary, as you are
only seeing an external representation: internally, bash
keeps the timestamp separate (as happens to the seq number,
too).

In the external file, the timestamps are kept as #-comments
in separate lines (with the UNIX timestamps in them).

> That means that history expansion
> can still function, for example entering !502
> interactively will run line number 502, but
> only the 'env' that comes after the semicolon
> will have any effect.

I tried it out, and this also works with a "naked" timestamp,
without the : ... ; wrapping.

Caveat: I only tried with bash.

Cheers
-- 
t


signature.asc
Description: PGP signature