On Ma, 02 iul 19, 08:02:22, The Wanderer wrote:
> On 2019-07-01 at 03:47, Curt wrote:
> >
> > https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names
>
> I'm skeptical as to whether this is (still/currently) accurate.
This was fixed in the mean
On 2/07/19 9:13 PM, Gene Heskett wrote:
> On Monday 01 July 2019 19:42:08 David Wright wrote:
>
>> On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
>>> On Monday 01 July 2019 09:33:35 David Wright wrote:
On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
>>> Whole filesys
The Wanderer wrote:
On 2019-07-02 at 10:10, Curt wrote:
On 2019-07-02, The Wanderer wrote:
Not even that, it seems (no longer affects systemd).
Have you confirmed that? It seems possible that on a systemd
machine, things in other packages (such as whatever would provide
that 99-default.lin
On Tue 02 Jul 2019 at 10:22:56 -0400, The Wanderer wrote:
> On 2019-07-02 at 10:10, Curt wrote:
>
> > On 2019-07-02, The Wanderer wrote:
> >
> >>> Not even that, it seems (no longer affects systemd).
> >>
> >> Have you confirmed that? It seems possible that on a systemd
> >> machine, things in
On 2019-07-02 at 10:10, Curt wrote:
> On 2019-07-02, The Wanderer wrote:
>
>>> Not even that, it seems (no longer affects systemd).
>>
>> Have you confirmed that? It seems possible that on a systemd
>> machine, things in other packages (such as whatever would provide
>> that 99-default.link fil
On 2019-07-02, The Wanderer wrote:
>> Not even that, it seems (no longer affects systemd).
>
> Have you confirmed that? It seems possible that on a systemd machine,
> things in other packages (such as whatever would provide that
> 99-default.link file, which unfortunately - because it's under /et
On 2019-07-02 at 09:10, Greg Wooledge wrote:
> On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
>
>> On 2019-07-02 at 08:37, Curt wrote:
>>
>>> Not even that, it seems (no longer affects systemd).
>>
>> Have you confirmed that?
>
> I'm using systemd, and the 70-* file was used whe
On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
> On 2019-07-02 at 08:37, Curt wrote:
> > Not even that, it seems (no longer affects systemd).
>
> Have you confirmed that?
I'm using systemd, and the 70-* file was used when I upgraded to buster,
but that was roughly 2 months ago. I
On 2019-07-02 at 08:37, Curt wrote:
> On 2019-07-02, The Wanderer wrote:
>> /usr/share/doc/udev/README.Debian.gz has a section on the subject
>> of migration from the old naming scheme to the new one. Although it
>> does not seem to state as much explicitly, from that section (and
>> other parts
On 2019-07-02, The Wanderer wrote:
>> https://www.debian.org/releases///buster/s390x/release-notes/ch-informa=
> tion.en.html#migrate-interface-names
>
> (Any particular reason you linked to the s390x version of the release
> notes? It seems to match e.g. the amd64 one for this purpose, so it
> s
On 2019-07-01 at 03:47, Curt wrote:
> Another, less serious, gotcha for those inveterate upgraders and
> newbies who don't read the release notes is that
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> mechanism for defining device names. This mechanism (automagically)
> pe
ight factor in is the size of the user-base
> > > > > for the troublesome package. I'm surprised to find that it's
> > > > > extremely small according to popcon data: less than 1% of
> > > > > reporters:
> > > > > https://qa.
f very bad PR.
> > > >
> > > > It's the release teams call, generally speaking, and one of the
> > > > things they might factor in is the size of the user-base for the
> > > > troublesome package. I'm surprised to find th
crypt, ecryptfs or encfs are of
use to you. GnuPG could do what you describe there, amongst other things.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.
aking, and one of the
> > > things they might factor in is the size of the user-base for the
> > > troublesome package. I'm surprised to find that it's extremely
> > > small according to popcon data: less than 1% of reporters:
> > > https://qa.debian.
ngs they might factor in is the size of the user-base for the
> >> troublesome package. I'm surprised to find that it's extremely
> >> small according to popcon data: less than 1% of reporters:
> >> https://qa.debian.org/popcon.php?package=ecryptfs-utils
On 2019-07-01, Greg Wooledge wrote:
>> >
>> > For whatever it's worth, when I upgraded this machine from stretch to
>> > buster a couple months ago, it continued using eth0 as the interface
>> > name without any immediately obvious issues. I did the conversion to
>> > "predictable interface names
On Mon, Jul 01, 2019 at 02:15:50PM -, Curt wrote:
> On 2019-07-01, Greg Wooledge wrote:
> > On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
> >> Another, less serious, gotcha for those inveterate upgraders and newbies
> >> who don't read the release notes is that
> >> '/etc/udev/rules.d/
On 2019-07-01, Greg Wooledge wrote:
> On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
>> Another, less serious, gotcha for those inveterate upgraders and newbies
>> who don't read the release notes is that
>> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
>> mechanism for d
On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
> Another, less serious, gotcha for those inveterate upgraders and newbies
> who don't read the release notes is that
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> mechanism for defining device names.
For whatever it's wo
On 2019-07-01, Jonathan Dowland wrote:
> On Mon, Jul 01, 2019 at 01:14:07PM -, Curt wrote:
>>The second triad of NUMBER % RANK columns corresponds to the number of people
>>using the package regularly* and by that metric ecryptfs-utils beats encfs by
>>a
>>rela
On Mon, Jul 01, 2019 at 01:14:07PM -, Curt wrote:
The second triad of NUMBER % RANK columns corresponds to the number of people
using the package regularly* and by that metric ecryptfs-utils beats encfs by a
relative long shot (1066 to 630, 0.58% to 0.34%).
"relative" to what? T
On Mon, Jul 01, 2019 at 08:33:35AM -0500, David Wright wrote:
The grey area is for me is the relative benefit of encrypting file by
file compared with the whole partition. Assuming that there's just one
passphrase involved in each scenario, is more protection given by the
former method? After all
e troublesome
> > package. I'm surprised to find that it's extremely small according to
> > popcon data: less than 1% of reporters:
> > https://qa.debian.org/popcon.php?package=ecryptfs-utils
> >
> > Compare just two alternatives:
> >
> > encfs
ackage. I'm surprised to find that it's extremely small according to
>> popcon data: less than 1% of reporters:
>> https://qa.debian.org/popcon.php?package=ecryptfs-utils
>>
>> Compare just two alternatives:
>>
>> encfs: 1.14% https://qa.debian.org/popco
according to
> popcon data: less than 1% of reporters:
> https://qa.debian.org/popcon.php?package=ecryptfs-utils
>
> Compare just two alternatives:
>
> encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup
That does
, generally speaking, and one of the things
they might factor in is the size of the user-base for the troublesome
package. I'm surprised to find that it's extremely small according to
popcon data: less than 1% of reporters:
https://qa.debian.org/popcon.php?package=ecryptfs-utils
Compare
On 2019-06-30, Andrea Borgia wrote:
> Il 30/06/19 11:52, Curt ha scritto:
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>>
>> Due to #765854 ecryptfs-utils has been removed from Buster.
>> The kernel module (ecryptfs.ko) is still built but depe
Tixy wrote:
> Or if you have (or can make) a new disk partition, use dm-crypt to
> encrypt that and put the file system on that that people want encrypted
> (for /home?).
>
> Personally, for several releases I've used dm-crypt with LUKS for a
> partiton containing everything apart from /boot. (Do
On Sun, 2019-06-30 at 18:17 +0200, Sven Hartge wrote:
> Andrea Borgia wrote:
> > Il 30/06/19 11:52, Curt ha scritto:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
> > >
> > > Due to #765854 ecryptfs-utils has been removed from Buster.
> &
Il 30/06/19 18:17, Sven Hartge ha scritto:
Other than that: Reinstalling the system with full disk encryption or
just copying the files from the ecryptfs and then removing it are the
only real other options.
I'll explore f.d.e. for the laptop, I guess the desktop can live just
fine w
On Sunday 30 June 2019 12:17:48 Sven Hartge wrote:
> Andrea Borgia wrote:
> > Il 30/06/19 11:52, Curt ha scritto:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
> >>
> >> Due to #765854 ecryptfs-utils has been removed from Buster.
> >&g
Andrea Borgia wrote:
> Il 30/06/19 11:52, Curt ha scritto:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>>
>> Due to #765854 ecryptfs-utils has been removed from Buster.
>> The kernel module (ecryptfs.ko) is still built but depending on the
>
Il 30/06/19 11:52, Curt ha scritto:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
Due to #765854 ecryptfs-utils has been removed from Buster.
The kernel module (ecryptfs.ko) is still built but depending on the
upgrade path users will be unable to mount their encrypted home
I was preparing an upgrade to Buster until I saw this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
Due to #765854 ecryptfs-utils has been removed from Buster.
The kernel module (ecryptfs.ko) is still built but depending on the
upgrade path users will be unable to mount their
On Mi, 10 apr 19, 15:40:13, Pierre Fourès wrote:
>
> I did the test and all went as expected. I got ecryptfs-utils being
> installed with the four of its dependencies. One of them, keyutils, is
> in 1.5.9-9 in stretch and 1.6.6 in buster. As expected, apt installed
> the one fro
On Thu, 11 Apr 2019 20:56:04 -0700
David Christensen wrote:
...
> If I remember encfs correctly, encfs is designed to provide exclusive
> access to the user who mounts an encrypted folder -- no other user,
> including root, can see the plaintext.
My understanding is that while this is technic
ecryptfs,
would I require to go away from it doesn't get reintegrated in Debian.
This drove me to gave a look to see if ecryptfs is still actively
maintained and it seems to be the case as the last commit dates from
2019-02-16 [1]. The package is also announced in [2] as heavily used
in U
;> crypttab(5) and cryptsetup(8)). I like the fact that it operates at the
> >> device level, so everything on an encrypted disc or partition is
> >> automatically and inescapably encrypted. File system level encryption,
> >> such as ecryptfs(7), might make sen
or partition is
automatically and inescapably encrypted. File system level encryption,
such as ecryptfs(7), might make sense for cloud directories or
sneaker-net media. I use ccrypt(1) for individual files, but vim(1) has
an encrypted mode that is very appealing for certain use-cases.
Indeed
the package and install it manually via dpkg (and do this with all it
dependencies). My point was to revert back to what buster was before
the removal of this package. However, the versions of package
ecryptfs-utils are currently the same between stretch, buster and sid.
So the .deb file will stay in
tomatically and inescapably encrypted. File system level encryption,
> such as ecryptfs(7), might make sense for cloud directories or
> sneaker-net media. I use ccrypt(1) for individual files, but vim(1) has
> an encrypted mode that is very appealing for certain use-cases.
>
Indeed, I&#
e a custom installed Linux, or on OSX
or Windows). Theses virtual machines usually ends on laptops. In order
to keep safe the company's data in case of a laptop being stolen, we
set up an encrypted home with ecryptfs-utils.
More over, the install process of Desktop machines is standardized
or Windows). Theses virtual machines usually ends on laptops. In order
to keep safe the company's data in case of a laptop being stolen, we
set up an encrypted home with ecryptfs-utils.
More over, the install process of Desktop machines is standardized and
shared with bare-metal machines. I inst
Hello,
I tried to set up an eCryptfs onto an CIFS share which resulted in an
incredibly slow transfer rate. The CIFS share is located on a QNAP NAS
with Gbit-Ethernet connection.
The CIFS share was normally mounted with:
$ mount -o username=guest,password=guest -t cifs //nas/Public /tmp/test
gt; For the record, purging systemd-sysv and installing sysvinit-core
> again got rid of that nasty bug. I would like to file a bug report,
> but I'm not sure which package is really at fault here – systemd or
> ecryptfs?
You can fill bug against ecryptfs. If maintainer (or someone other)
would like to file a bug report, but I'm
not sure which package is really at fault here – systemd or ecryptfs?
I also looked through all the crontabs installed on my system, nothing
there is executed at 0:00, but the filesystem gets unmounted exactly at
0:00, so it cannot be cron's f
Hi,
lately I'm having problems with my ecryptfs home directory, which is
being unmounted while I'm still logged in and working on my machine. It
seems to be unmounted at around 0:00 every night, which has the effect
that some of my running applications stop working until I mount it a
On Tue, Mar 22, 2011 at 10:22 AM, Jon Dowland wrote:
> On Mon, Mar 21, 2011 at 08:51:27PM -0700, Todd A. Jacobs wrote:
>
> With ecryptfs, I can have a file-level backup solution work on the backing
> files, not require an active login or mounted FS, and do replication to other
&
x27;ve been using the dm-crypt approach for a while, but the limitations of it
have encouraged me to plan a migration to ecryptfs.
* If you mount via root/boot time, you must supply the passphrase at boot,
which stops unattended/automated restarts or boot-ups.
* as a user, you must su
On Mon, Mar 21, 2011 at 11:51 PM, Todd A. Jacobs
wrote:
> On Mon, Mar 21, 2011 at 8:09 PM, Dan wrote:
>> I would like to encrypt some folders in the home directory of the
>> users in a server. I have seen that there are 2 choices ecryptfs and
>> encfs. They seem to be very
On Mon, Mar 21, 2011 at 8:09 PM, Dan wrote:
> I would like to encrypt some folders in the home directory of the
> users in a server. I have seen that there are 2 choices ecryptfs and
> encfs. They seem to be very similar. Which one do you think that it is
> better?
One isn'
Hi,
I would like to encrypt some folders in the home directory of the
users in a server. I have seen that there are 2 choices ecryptfs and
encfs. They seem to be very similar. Which one do you think that it is
better?
Thanks,
Dan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
I'm trying to create an encrypted directory using ecryptfs such that I
can switch it between being encrypted to non-encrypted at will. I did:
# aptitude install ecryptfs-utils
# modprobe ecryptfs
# mkdir encrypted-directory
# chmod 700 encrypted-directory
# mount -t ecryptfs encr
Hi,
On Mon, Nov 03, 2008 at 02:50:31PM -0500, Paul Cartwright wrote:
> Bob Cox wrote:
> >>> [EMAIL PROTECTED]:~$ apt-file search ecryptfs-setup-private
> >>> ecryptfs-utils: /usr/bin/ecryptfs-setup-private
> >>> ecryptfs-utils: /usr/share/man/man1/ecryptfs-s
Bob Cox wrote:
>>> [EMAIL PROTECTED]:~$ apt-file search ecryptfs-setup-private
>>> ecryptfs-utils: /usr/bin/ecryptfs-setup-private
>>> ecryptfs-utils: /usr/share/man/man1/ecryptfs-setup-private.1.gz
>>>
>>> This is with lenny.
>>>
>> loo
On Mon, Nov 03, 2008 at 14:08:31 -0500, Paul Cartwright ([EMAIL PROTECTED])
wrote:
> Bob Cox wrote:
> > On Mon, Nov 03, 2008 at 06:46:30 -0500, Paul Cartwright ([EMAIL PROTECTED])
> > wrote:
> >
> >> I was reading a ubuntu how-to on ecryptfs ( for my lapt
On Mon, Nov 03, 2008 at 06:46:30 -0500, Paul Cartwright ([EMAIL PROTECTED])
wrote:
> I was reading a ubuntu how-to on ecryptfs ( for my laptop) and was
> interested in installing it on my Debian desktop. the ecryptfs-utils app
> installed just fine, but there was no user program
&g
I was reading a ubuntu how-to on ecryptfs ( for my laptop) and was
interested in installing it on my Debian desktop. the ecryptfs-utils app
installed just fine, but there was no user program
(ecryptfs-setup-private ), per this doc:
https://help.ubuntu.com/community/EncryptedPrivateDirectory
to
59 matches
Mail list logo
