Re: Correct: System Thinks Hardware Clock is UTC

[Felix Miata]

Michael Stone composed on 2018-05-21 10:05 (UTC-0400):

> On Mon, May 21, 2018 at 09:55:42AM -0400, Felix Miata wrote:

>>OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and 
>>UTC
>>isn't fun, especially with one or more that can't not, which is what I have 
>>with
>>a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
>>option. 

> I'm afraid I don't understand how things like old standalone boxes 
> impact what makes sense going forward. You do understand that there's no 
> relationship between the RTC clock and the displayed time? (That is, you 
> can set the RTC to UTC and still interact with the system in local 
> time.)

Typically, I record on a STB that has no support for /etc/adjtime or
/etc/localtime and see via FTP login the new recording's timestamp is tomorrow
until I wait several hours, and then see it was "recorded" hours after the
program guide and my clock said it aired. I live in today, not tomorrow, and
have no interest in clock time outside an hour or two's drive from home.
Different timestamps across the LAN interfere with evaluation which files of
same name are the newer when choosing, copying, backing up or restoring.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: making more room in root partition for distribution upgrade

[Pascal Hambourg]

Le 21/05/2018 à 22:09, Abdullah Ramazanoğlu a écrit :

On Mon, 21 May 2018 21:48:33 +0200 Pascal Hambourg said:


The purpose of RAID 1 is to provide redundancy and availability, not
performance.
What do you think happens to a running system when one half of the swap
suddenly becomes unavailable after a disk failure ?


I would agree mirroring swap for a mission critical server. Otherwise it would
be an overkill, IMO.

If one of the non-mirrored swaps go down, then I will get a system crash. So?


So you lose system availability. If you can stand this, then you don't 
need availability.

Re: Laptop randomly reboots

[David Wright]

On Sat 19 May 2018 at 12:49:51 (-0500), Sam Smith wrote:
> On 05/19/2018 01:56 AM, Hans wrote:
> >Hi,
> >
> >looks like the laptop is going too hot. This is a problem at many laptops.
> >because of the cooler is set with dust.
> >
> >Take a look at the cooling system, if there is any dust in the way.
> >Especially, as you told, this is a used one, take care of good cooling.
> >
> >Sadly you have to open the laptop and take a look.
> >
> >It might be, that the cooling is enough, when at normal load, but at high 
> >load
> >at some point, the cooling is no more enough and the laptop reboots or is
> >shutting down.
> >
> >If this is the reason, there should be a log entry in syslog.
> >
> >There is also some packages, from which can  the sensors can be watched.
> >Check lm-sensors or similar.
> >
> >Hope this helps.
> >
> >Good luck!
> >
> >Hans
> 
> 
> I don't think that is the case. Perhaps, something, somewhere might
> think it is getting too hot (an in a software, firmware issue). But
> I've never had it reboot during any times of stressing. I used to
> use a program 'think-fan' to control the fans. With that, it never
> got above 80*c. I removed the program (thinking that perhaps
> something external controlling the fans was causing some embedded
> controller to freak out and restart the machine or something). I've
> since uninstalled it, and with stock control, the temps get to 90*c,
> but as I've said, doing video encoding for hours or any other stress
> testing has never caused an issue. It seems to reboot at surreal
> times, like I'll be typing and stop to take a sip of coffee then
> boom, screen goes black and then I'm watching grub load up.

You have my sympathy. This laptop that runs hot when busy (up to
98.5°C; I underreported the maximum a week ago) has never frozen or
rebooted when particularly stressed. However, during the time of
squeeze, it would turn itself off spontaneously (hard power-off
like holding the power button), usually when you disturbed the
angle of the screen (even slightly).

It never happened after installing wheezy, but since about a year
ago the screen goes very dark after a second or two. That happens
at boot up (before the POST is finished) and also when exiting X
to a VC (normal for a second, then dark again). These fleeting
glimpses are the reason I can't ever seriously upgrade it. I use
it with a monitor but that get a signal during the POST or CMOS.

So maybe you're lucky and it'll just go away, but it sounds as if
you have a reasonable workaround. (I've never run a laptop for as
long as those uptimes you're reporting.)

Cheers,
David.

Re: making more room in root partition for distribution upgrade

[Pascal Hambourg]

Le 21/05/2018 à 21:03, Abdullah Ramazanoğlu a écrit :


Forgot to add that in a raid-1 setup swap partition*s* should not be mirrored.


Of course they should be mirrored in RAID 1 too. Otherwise it defeats 
the purpose of RAID 1.



There should be 2 separate non-mirrored swap partitions, one on each drive, for
better swap performance (distributed I/O).


The purpose of RAID 1 is to provide redundancy and availability, not 
performance.
What do you think happens to a running system when one half of the swap 
suddenly becomes unavailable after a disk failure ?

Re: making more room in root partition for distribution upgrade

[Pascal Hambourg]

Le 21/05/2018 à 18:52, Mark Copper a écrit :


The release notes even give detailed instructions as to how you might mount
bind (or is bind mount?) a usb key as a temporary /var/cache/apt/archives
directory.


That's an intriguing idea.  I'll look.  Thanks.


There is plenty of free space in /home, so no need to use a (slow and 
unreliable) USB drive.

Re: making more room in root partition for distribution upgrade

[Pascal Hambourg]

Le 21/05/2018 à 18:14, Mark Copper a écrit :

On Sun, May 20, 2018 at 3:19 AM, Pascal Hambourg  wrote:

Le 18/05/2018 à 02:05, Mark Copper a écrit :

You will have to move/delete and re-create the swap too.
Gparted allows to resize and move an unused partition. Better have a backup
though.


yes, if I understand, the file system is lost on any partition,
primary or logical, whose first cylinder is changed.


Not with Gparted. Gparted moves the data to the new location of the 
partition. But things can go wrong during the operation (power failure, 
system crash...) so better keep a backup.


Note : cylinders are deprecated. LBA is used instead.


6.5G/usr


What about the rest ? How much free space is available ?

(...)

Yes, should have included that:

:~# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1   9.1G  7.8G  870M  91% /


the other filesystems are of no interest. I meant the rest of the / 
filesystem.



No, I had not considered playing with any part of /var. With /var
taking less than 1 gb and /var/cache/apt/archives less than 1mb


/var/cache/apt/archives will temporarily grow a lot during the upgrade, 
as it will contain all the dowloaded *.deb files. When apt-get says 
"Need to get X MB of archives", it means that these X MB will go into 
/var/cache/apt/archives.

Re: O/S upgrade - dpkg still shows old version for some packages

[Greg Wooledge]

On Mon, May 21, 2018 at 11:29:53AM +, John Horne wrote:
> dpkg -p nodejs
> ...
> Version: 0.10.37-1chl1~lucid1
> 
> nodejs -v
> v4.8.2

You probably have nodejs installed locally, outside of the packaging
system.  What does "type -a nodejs" tell you (in bash)?

O/S upgrade - dpkg still shows old version for some packages

[John Horne]

Hello,

We have a virtual Debian 7 (LTS) server, and I have been running through the
upgrade process of going from 7 to 8 and then straight to Debian 9. Generally
no problems with this.

However, when using 'dpkg -p' I notice that some of the packages are showing
their old (debian 7) version numbers. I know the packages have been updated
since (typically) using a '--version' option for the command shows the later
version, and if I try and install the package dpkg says that it is already at
the latest version.
For example:

(This package was installed on Deb 7 using a specific APT sources.list file.
That file was removed prior to the upgrade to Debian 8.)

dpkg -p nodejs
...
Version: 0.10.37-1chl1~lucid1

nodejs -v
v4.8.2

apt-get install nodejs
...
nodejs is already the newest version (4.8.2~dfsg-1).


dpkg -p memcached
...
Version: 1.4.13-0.2+deb7u4

memcached -V
memcached 1.4.33


I'm not completely familiar with how Debian records package versions, but I
assume that for some reason during the upgrade the relevant files were not
updated.

Can anyone advise how we may get 'dpkg -p' to show the correct (currently
installed) versions?



Thanks,

John.

--
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK

[http://www.plymouth.ac.uk/images/email_footer.gif]

This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the information contained 
is strictly prohibited and you should not rely on it. If you have received this 
email in error please let the sender know immediately and delete it from your 
system(s). Internet emails are not necessarily secure. While we take every 
care, Plymouth University accepts no responsibility for viruses and it is your 
responsibility to scan emails and their attachments. Plymouth University does 
not accept responsibility for any changes made after it was sent. Nothing in 
this email or its attachments constitutes an order for goods or services unless 
accompanied by an official order form.

Re: making more room in root partition for distribution upgrade

[Mark Copper]

>
> The release notes even give detailed instructions as to how you might mount
> bind (or is bind mount?) a usb key as a temporary /var/cache/apt/archives
> directory.
>

That's an intriguing idea.  I'll look.  Thanks.

Re: making more room in root partition for distribution upgrade

[Curt]

On 2018-05-21, Mark Copper  wrote:
>
> No, I had not considered playing with any part of /var. With /var
> taking less than 1 gb and /var/cache/apt/archives less than 1mb, /usr
> had seemed the elephant in the room. Might that be a way to go? I just
> need to get to Stretch for now.

There's actually advice in the release notes to that effect (along with other
strategies for freeing or finding necessary space):

https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#package-status

A command can be run that supposedly will warn the constrained user if
she hasn't enough room on disk for the upgrade (this after modifying the
/etc/apt/sources.list file to point to Stretch and running apt(-get)
update

 apt-get -o APT::Get::Trivial-Only=true dist-upgrade

This failed to work as promised in my case (or I failed somehow
somewhere along the line), and I ran out of room during my upgrade, but
bungled through. I will spare the forum the gruesome details of my
struggle.

The release notes even give detailed instructions as to how you might mount
bind (or is bind mount?) a usb key as a temporary /var/cache/apt/archives
directory.

Good luck.

> Thank you.
>
>


-- 

Re: making more room in root partition for distribution upgrade

[Mark Copper]

On Sun, May 20, 2018 at 3:19 AM, Pascal Hambourg  wrote:
> Le 18/05/2018 à 02:05, Mark Copper a écrit :
>>>
>>>
 There was a day when a 10 gb partition seemed like plenty of space to
 leave
 for the system but now it's not. An upgrade to Stretch appears to need
 more.
>
>
> How do you know ?

I don't, actually. I'm reacting to warnings of limited space received
when upgrading Jessie. And previously when upgrading from Wheezy IIRC.

>
 Device BootStart   End   Sectors   Size Id Type
 /dev/sda1  *2048  19531775  19529728   9.3G 83 Linux
 /dev/sda2   19533822 312580095 293046274 139.8G  5 Extended
 /dev/sda5   19533824  27578367   8044544   3.9G 82 Linux swap /
 Solaris
 /dev/sda6   27580416 312580095 284999680 135.9G 83 Linux

 $ cat /etc/fstab
 # / was on /dev/sda1 during installation
 # /home was on /dev/sda6 during installation
 # swap was on /dev/sda5 during installation
>
>
 This must be a FAQ. But there appear to be two ways forward.

 1. Back-up /home, enlarge / partition, copy back-up back to new, smaller
 /home partition (because /home will then start on a different cylinder
 so
 data will be lost).
>
>
> You will have to move/delete and re-create the swap too.
> Gparted allows to resize and move an unused partition. Better have a backup
> though.

yes, if I understand, the file system is lost on any partition,
primary or logical, whose first cylinder is changed.

>
 2. Carve out a new partition for /usr at end of disk which will free up
 over 6 gb.
>
>
> The Debian initramfs supports a separate /usr since Jessie.

Given the system as it currently exists, this seems the easiest way to
go. (actually there are several boxes like this needing attention).

>
>> $ du -h /var
>> ...
>> 598M/var
>>
>> but
>>
>> $ du -h /usr
>> ...
>> 4.2G/usr/share
>> 6.5G/usr
>
>
> What about the rest ? How much free space is available ?
> Maybe the upgrade requires more space in order to download and store the new
> packages. Have you considered moving /var/cache/apt/archives to the /home
> partition (through a symlink or bind mount) so that downloaded packages do
> not use space in the / filesystem ?
>

Yes, should have included that:

:~# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1   9.1G  7.8G  870M  91% /
udev 10M 0   10M   0% /dev
tmpfs   402M  6.1M  396M   2% /run
tmpfs  1005M   92K 1005M   1% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
tmpfs  1005M 0 1005M   0% /sys/fs/cgroup
/dev/sda6   134G  6.0G  121G   5% /home
tmpfs   201M  8.0K  201M   1% /run/user/1000
/dev/sdb3   915G  5.8G  863G   1% /media/mark/d-live 9.4.0 gn amd64
/dev/sdb1   2.3G  2.3G 0 100% /media/mark/d-live 9.4.0 gn amd641

No, I had not considered playing with any part of /var. With /var
taking less than 1 gb and /var/cache/apt/archives less than 1mb, /usr
had seemed the elephant in the room. Might that be a way to go? I just
need to get to Stretch for now.

Thank you.

Re: Correct: System Thinks Hardware Clock is UTC

[Patrick Bartek]

On Mon, 21 May 2018 09:03:47 -0400 Greg Wooledge 
wrote:

> On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:
> > > > Haven't
> > > > installed any other OS on this system since Wheezy 5 years ago.
> 
> Oh, good, then you can simply set the hardware cl--

I did so.  And everything is fixed as far as I can tell. But had to
reboot Stretch install a couple times before it took. Although, I'm
thinking now I should just reinstall. It's still only a Base
Terminal only system so far. I've yet to flesh it out.  So, no great
loss.

> > Unfortunately, I have other OSes on this system and they are
> > configured for the hardware clock set to local time. I need to keep
> > it that way.
> 
> Um... OK.  This sudden reversal is confusing to me, but if you've got
> it dual-booting between Windows and Linux, then setting the HW clock
> to local time may be your simplest option.

Sorry for the confusion.  I guess my initial post wasn't detailed
enough.

> In past versions of Debian, this was done by editing
> the /etc/default/rcS file.  But that's not true in stretch.

I looked into that as well since I converted Stretch init to sysvinit 

> If I'm reading the man pages and the /etc/init.d/* scripts correctly
> (as you said you're using sysv-rc rather than systemd), it looks like
> the setting for HW clock to UTC or local is in the /etc/adjtime file
> now.  There's no separate man page for it.  The documentation for
> /etc/adjtime appears to be in the hwclock(8) man page, under the
> section header "The Adjtime File".

Read that, too.  And tried changing UTC to LOCAL. No effect even after a
reboot.  Later discovered that /etc/adjtime is only accessed when the
hardware clock is reset.  FWIW, if that file doesn't exist, the default
is UTC.

Thanks for your input.

B

Envie sua proposta de logo para a DebConf19 até 27 de maio

[Paulo Henrique de Lima Santana]

Olá,

Em julho de 2019 Curitiba sediará a 20a edição da DebConf - Conferência Mundial 
de Desenvolvedores(as) do Projeto Debian (conhecida como DC19), e você pode 
desde já contribuir para o sucesso do evento!

Como acontece tradicionalmente, a organização da DebConf abriu um concurso 
bastante simples para a escolha da logo que identificará a DC19 em Curitiba. 
Prorrogamos o prazo e agora você pode enviar quantas propostas quiser até às 
23h59m do dia 27/05/2018.

Sua proposta pode ser relacionada a Curitiba ou ao Brasil. Se quiser ver quais 
pontos turísticos temos em Curitiba, dê uma olhada aqui:
http://www.turismo.curitiba.pr.gov.br/categoria/atrativos-turisticos/3

Lá você encontrará vários prédios/monumentos como:
- Estufa do Jardim Botânico
- Prédio histórico da UFPR
- Ópera de Arame
- Museu Oscar Niemeyer
- Rua XV de Novembro

Existem outras coisas que representam Curitiba e/ou Paraná como:
- Pinhão (https://pt.wikipedia.org/wiki/Pinh%C3%A3o)
- Araucária (a árvore que dá o pinhão)
- Os 4 climas em um dia (calor, frio, chuva, sol)
- A frase "leite quente dá dor de dente na gente" com sotaque curitibano 
(https://www.youtube.com/watch?v=ZBvBzofL_1g)
- Pássaro Gralha-azul
- Ruas feitas de petit pavê com desenhos dos símbolos 
(http://levecuritiba.com.br/colecoes/petit-pave)
- Capivara
- Paulo Leminski
- Poty Lazzarotto (e suas obras)

Veja mais detalhes sobre o concurso:
https://wiki.debconf.org/wiki/DebConf19/Artwork/LogoProposals

Qualquer dúvida, mande email para: l...@dc19.curitiba.br

Lembramos que não haverá premiação em dinheiro para a logo vencedora, mas você 
receberá uma camiseta e o nosso "muito obrigado" da comunidade Debian :-)

Abraços,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt

Re: Correct: System Thinks Hardware Clock is UTC

[Michael Stone]

On Mon, May 21, 2018 at 09:55:42AM -0400, Felix Miata wrote:

OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and UTC
isn't fun, especially with one or more that can't not, which is what I have with
a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
option. 


I'm afraid I don't understand how things like old standalone boxes 
impact what makes sense going forward. You do understand that there's no 
relationship between the RTC clock and the displayed time? (That is, you 
can set the RTC to UTC and still interact with the system in local 
time.)


Mike Stone

Re: making more room in root partition for distribution upgrade

[David Wright]

On Mon 21 May 2018 at 05:50:27 (+), Andy Smith wrote:
> Hello,
> 
> On Sun, May 20, 2018 at 07:59:48PM -0400, songbird wrote:
> > Pascal Hambourg wrote:
> > > Then LVM is your friend. You can create as many logical volumes as you 
> > > like with minimal sizes and easily extend them when needed. This way you 
> > > don't waste space in overprovisioning.
> > 
> >   added complexity for a simple system such as mine
> > is rather pointless.
> 
> I hear that a lot from people who later find themselves doing
> cosmetic surgery on their partition table because they weren't able
> to initially size things properly.

It's called sampling bias. You're not going to hear from all the
people who are happy with their choices of partition sizes.

Two more biases:

There seems to be some kudos for running a slimly partitioned system.
Nobody's going to brag about a system with a 100GB root partition.

And then there's history/lag/call it what you will. My first Debian
(buzz) ran on a 2GB drive. Any post from a few years ago is likely to
report partition sizes that now seem rather on the small side.
As for appendix C in the Installation Manual, well that looks like
a bit of a joke: who's running linux in 256MB memory, let alone 16MB?

Like with Joe, as disk replacements have got larger over time, so have
my root partitions. 16GB has proved adequate for two laptops that are
seriously into their dotage, and I now create ones sized ~36GB.
(I should say "twos" rather than "ones", as I always create them in
pairs.)  Not forgetting the ef00 and ef02 partitions too, even if
they're never used in anger.

Cheers,
David.

Re: Correct: System Thinks Hardware Clock is UTC

[Felix Miata]

Michael Stone composed on 2018-05-21 09:10 (UTC-0400):

> On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:

>>Unfortunately, I have other OSes on this system and they are configured
>>for the hardware clock set to local time. I need to keep it that way.

> For what it's worth, you'll have less long term pain if you also 
> configure those to use UTC. Lots of hilarity can ensue when multiple OSs 
> decide they need to reset the local time for DST changes...

> It's good that MS did eventually figure this out, and provide a 
> mechanism to specify that the HW clock is UTC.

OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and UTC
isn't fun, especially with one or more that can't not, which is what I have with
a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
option. So I keep most on LOCAL, and reboot those that would otherwise be online
as close as I can following each change hour. Those with Windows installed I
configure to not mess with the hardware clock at change times, leaving Linux to
do the deed.

Last fresh installation that got time out of sync with hardware clock was fixed
simply with a change of /etc/adjtime from UTC to LOCAL followed by reboot.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Correct: System Thinks Hardware Clock is UTC

[Michael Stone]

On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:

Unfortunately, I have other OSes on this system and they are configured
for the hardware clock set to local time. I need to keep it that way.


For what it's worth, you'll have less long term pain if you also 
configure those to use UTC. Lots of hilarity can ensue when multiple OSs 
decide they need to reset the local time for DST changes...


It's good that MS did eventually figure this out, and provide a 
mechanism to specify that the HW clock is UTC.


Mike Stone

Re: Correct: System Thinks Hardware Clock is UTC

[Greg Wooledge]

On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:
> > > Haven't
> > > installed any other OS on this system since Wheezy 5 years ago.

Oh, good, then you can simply set the hardware cl--

> Unfortunately, I have other OSes on this system and they are configured
> for the hardware clock set to local time. I need to keep it that way.

Um... OK.  This sudden reversal is confusing to me, but if you've got
it dual-booting between Windows and Linux, then setting the HW clock to
local time may be your simplest option.

In past versions of Debian, this was done by editing the /etc/default/rcS
file.  But that's not true in stretch.

If I'm reading the man pages and the /etc/init.d/* scripts correctly
(as you said you're using sysv-rc rather than systemd), it looks like
the setting for HW clock to UTC or local is in the /etc/adjtime file
now.  There's no separate man page for it.  The documentation for
/etc/adjtime appears to be in the hwclock(8) man page, under the section
header "The Adjtime File".

Re: making more room in root partition for distribution upgrade

[David Baron]

Yep. I ended up buying a second disk and moving everything around. The
installation is awful.

On Mon, May 21, 2018, 3:13 PM Pascal Hambourg 
wrote:

> Le 21/05/2018 à 10:26, Curt a écrit :
> >
> > Verily in the installer I chose automatic partitioning because of my
> > partitioning phobia many moons ago and was allotted a 9G '/' and a 1.4T
> > 'home' (as well as swap the size of my ego)
> (...)
> > (A recent thread seemed to imply that the installer's automagical
> > partitioner for LVM leaves little or no empty room for growth, thus
> > vitiating somewhat the very raison d'être of LVM at its root.)
>
> Bottom line : do not use guided partitioning.
>
> If you do not know what partition sizes you need, use LVM. Create
> volumes with minimal suitable sizes (you are not going to fill /home
> with 90% of the disk capacity at once, are you ?). This will leave
> plenty of free space. When you see that one volume begins to be filled,
> extend it. Simple and easy.
>
>

Re: making more room in root partition for distribution upgrade

[Pascal Hambourg]

Le 21/05/2018 à 10:26, Curt a écrit :


Verily in the installer I chose automatic partitioning because of my
partitioning phobia many moons ago and was allotted a 9G '/' and a 1.4T
'home' (as well as swap the size of my ego)

(...)

(A recent thread seemed to imply that the installer's automagical
partitioner for LVM leaves little or no empty room for growth, thus
vitiating somewhat the very raison d'être of LVM at its root.)


Bottom line : do not use guided partitioning.

If you do not know what partition sizes you need, use LVM. Create 
volumes with minimal suitable sizes (you are not going to fill /home 
with 90% of the disk capacity at once, are you ?). This will leave 
plenty of free space. When you see that one volume begins to be filled, 
extend it. Simple and easy.

Re: rsync vers un FTPS

[G2PC]

>> Etant un peu perdu dans mes recherches, je viens à vous !
>>
>> Le but est de sauvegarder plusieurs dossiers locaux vers un serveur
>> FTP
>> distant.
>> rsync parait sympa à utiliser !
>> (version ligne de commande only)
>>
>> Cependant, il faut une technique pour se connecter au serveur FTP
>> distant, qui propose aussi le chiffrement TLS sur le même port
>> d'écoute.
>>
>> Vers quelle voix devrais-je m'orienter ?
>> Et histoire d'être sûr que je ne me connecte pas en FTP sans
>> chiffrement, et balancer les login/pass en clair pendant mes tests :s
>>
> bonjour,
>
> te casses pas le baigneur avec ftp, faut passer à sftp :
>
> https://pantheon.io/docs/rsync-and-sftp/
>
> et pourquoi ne pas employer mc en mode sftp ?
>
> merci
>
> slt
> bernard
>

Bonjour, as tu des notes sur ta recherche que je puisse les consulter,
car, je n'ai pas encore finalisé la mise en pratique avec SSH / TLS.

Ici pour FTP
https://www.visionduweb.eu/wiki/index.php?title=Installer_et_utiliser_un_serveur_proFTPd_pureFTPd_vsFTPd

Ici pour MC, proposé par Bernard
https://www.visionduweb.eu/wiki/index.php?title=Installer_et_utiliser_Midnight_Commander#Connexion_sftp_avec_Midnight_Commander

Ici pour rsync / rsnapshot
https://www.visionduweb.eu/wiki/index.php?title=Sauvegarder_et_reinstaller_Linux#Rsync_et_Rsnapshot

Re: rsync vers un FTPS

[Bernard Schoenacker]

- Mail original -
> De: "Pierre L." 
> À: debian-user-french@lists.debian.org
> Envoyé: Lundi 21 Mai 2018 11:11:52
> Objet: rsync vers un FTPS
> 
> Bonjour,
> 
> Etant un peu perdu dans mes recherches, je viens à vous !
> 
> Le but est de sauvegarder plusieurs dossiers locaux vers un serveur
> FTP
> distant.
> rsync parait sympa à utiliser !
> (version ligne de commande only)
> 
> Cependant, il faut une technique pour se connecter au serveur FTP
> distant, qui propose aussi le chiffrement TLS sur le même port
> d'écoute.
> 
> Vers quelle voix devrais-je m'orienter ?
> Et histoire d'être sûr que je ne me connecte pas en FTP sans
> chiffrement, et balancer les login/pass en clair pendant mes tests :s
> 
> Merci d'avance :)
> 
> 

bonjour,

te casses pas le baigneur avec ftp, faut passer à sftp :

https://pantheon.io/docs/rsync-and-sftp/

et pourquoi ne pas employer mc en mode sftp ?

merci

slt
bernard

Cannot get crashdumps on iSCSI-booted system

[Eugene M. Zheganin]

Hello,


I'm trying to get the crashdumps (to start getting them automatically 
later) on an iSCSI-booted buster/sid, but after issuing |"echo c > 
/proc/sysrq-trigger" all I'm getting is the system hangup - no dump, but 
the system seems to be locked - and no panic screen or whatever. 
Everything is frozen up. However, I'm getting crashdumps when booting 
from local disks. The problem is - my production hosts use iSCSI for 
booting, so I really need to get these crashdumps whil on iSCSI. I know 
that Linux isn't able to write the crashdump on "local" disk when this 
"local" disk is iSCSI, so I've set up the NFS crashdump resource - but 
to NFS activity is happening when I'm triggering the panic.

|

|
|

|Is there some trick that I'm unaware of ?
|

|Thanks.|

|Eugene.
|

Re: ~ CD Burning Software

[Jonathan Dowland]

On Sat, May 19, 2018 at 11:36:35AM -0700, Herb Garcia wrote:

I'm running Mate on my laptop. I don't see a CD/DVD burning software
that came with the build. Any suggestions?


It's been a few years since I tried it, but I found Brasero to be
incredibly unreliable. I switched to wodim from the command-line and had
better success. But I'm now in the process of abandoning optical media
altogether.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

rsync vers un FTPS

[Pierre L.]

Bonjour,

Etant un peu perdu dans mes recherches, je viens à vous !

Le but est de sauvegarder plusieurs dossiers locaux vers un serveur FTP
distant.
rsync parait sympa à utiliser !
(version ligne de commande only)

Cependant, il faut une technique pour se connecter au serveur FTP
distant, qui propose aussi le chiffrement TLS sur le même port d'écoute.

Vers quelle voix devrais-je m'orienter ?
Et histoire d'être sûr que je ne me connecte pas en FTP sans
chiffrement, et balancer les login/pass en clair pendant mes tests :s

Merci d'avance :)



signature.asc
Description: OpenPGP digital signature

Re: making more room in root partition for distribution upgrade

[Joe]

On Mon, 21 May 2018 08:26:01 + (UTC)
Curt  wrote:

> On 2018-05-21, Andy Smith  wrote:
> > Hello,
> >
> > On Sun, May 20, 2018 at 07:59:48PM -0400, songbird wrote:  
> >> Pascal Hambourg wrote:  
> >> > Then LVM is your friend. You can create as many logical volumes
> >> > as you like with minimal sizes and easily extend them when
> >> > needed. This way you don't waste space in overprovisioning.  
> >> 
> >>   added complexity for a simple system such as mine
> >> is rather pointless.  
> >
> > I hear that a lot from people who later find themselves doing
> > cosmetic surgery on their partition table because they weren't able
> > to initially size things properly.  
> 
> Verily in the installer I chose automatic partitioning because of my
> partitioning phobia many moons ago and was allotted a 9G '/' and a
> 1.4T 'home' (as well as swap the size of my ego), so find myself in a
> predicament similar to that of the OP.
> 
> (A recent thread seemed to imply that the installer's automagical
> partitioner for LVM leaves little or no empty room for growth, thus
> vitiating somewhat the very raison d'être of LVM at its root.)
> 

I think a lot of resizing issues have just gone away, as hard drive
manufacturers have been able to increase [affordable] drive size even
faster than Microsoft has expanded Windows.

I don't run a hard drive online for more than about five years,
retiring it to backup duty after that. The replacement drive is
normally twice the size, or larger, and the original drive was large
enough for me to have allocated massively more space than necessary. So
resizing is rarely necessary in the life of one of my drives, and can
easily be performed at the changeover.

LVM snapshots are another matter. Over the years, I've not had any bad
luck backing up live (home) systems using online copies, but I've always
taken what precautions I could to minimise risk. Snapshots are a much
safer way of doing this, and the performance hit while the shadow copy
is active can be kept to a fairly short time. It does require a
significant chunk of unallocated space, though in an emergency, an
external drive can be temporarily added.

-- 
Joe

Re: Help with udev trigger

[Bhasker C V]

Thanks. I will try this

On Fri, May 18, 2018 at 12:21 PM, Reco  wrote:
> Hi.
>
> On Fri, May 18, 2018 at 09:26:47AM +0100, Bhasker C V wrote:
>> Hi,
>>
>>  Version: buster
>>  I do a manual cryptsetup to create my home directory after system boots up
>>  I want to run fsck every time the device node is created from luks
>>
>>  I added this udev rule
>>
>> ACTION="change",DEVTYPE="disk",ID_FS_UUID="cf1b64cf-7a62-4a43-ad44-6c68f2bbdec5"
>> RUN+="/bin/btrfsck /dev/mapper/home"
>>
>> But this rule is not getting triggered. Could someone help please to
>> point out what mistake I am doing ?
>
> You have five mistakes here, actually:
>
> 1) udev rules use C-like syntax for comparison (==) and assingment (=).
> Your rule tests nothing, it just assigns some values.
>
> 2) All udev 'attributes' have type, and you must specify it.
> For instance DEVTYPE and ID_FS_UUID are ENVIRONMENT.
>
> 3) 'change' applies to changing device state. It's 'add' for device
> creation.
>
> 4) RUN should go after a coma.
>
> 5) You're not supposed to spawn long-running processes from udev rules
> directly. Utilize systemd.
>
>
> Taking all this into the account, your rule should look like this (one
> like, coma separated values):
>
> ACTION=="add", 
> ENV{DEVTYPE}=="disk",ENV{ID_FS_UUID}=="cf1b64cf-7a62-4a43-ad44-6c68f2bbdec5",RUN+="/bin/systemctl
>  start my_brtfs_home_checking.service"
>
> Your custom service file - like this:
>
> [Service]
> Type=oneshot
> ExecStart=/bin/btrfsck /dev/mapper/home
>
> Reco
>

Re: making more room in root partition for distribution upgrade

[Curt]

On 2018-05-21, Andy Smith  wrote:
> Hello,
>
> On Sun, May 20, 2018 at 07:59:48PM -0400, songbird wrote:
>> Pascal Hambourg wrote:
>> > Then LVM is your friend. You can create as many logical volumes as you 
>> > like with minimal sizes and easily extend them when needed. This way you 
>> > don't waste space in overprovisioning.
>> 
>>   added complexity for a simple system such as mine
>> is rather pointless.
>
> I hear that a lot from people who later find themselves doing
> cosmetic surgery on their partition table because they weren't able
> to initially size things properly.

Verily in the installer I chose automatic partitioning because of my
partitioning phobia many moons ago and was allotted a 9G '/' and a 1.4T
'home' (as well as swap the size of my ego), so find myself in a
predicament similar to that of the OP.

(A recent thread seemed to imply that the installer's automagical
partitioner for LVM leaves little or no empty room for growth, thus
vitiating somewhat the very raison d'être of LVM at its root.)

> It's quite a manageable bit of learning that pays dividends for the
> whole rest of your time.
>
> Cheers,
> Andy
>


-- 

Re: CD Burning Software

[Joe]

On Mon, 21 May 2018 00:49:41 +0300
Abdullah Ramazanoğlu  wrote:

> On Sun, 20 May 2018 12:31:28 +0100 Joe said:
> > On Sat, 19 May 2018 22:10:04 +0300
> > Abdullah Ramazanoğlu  wrote:  
> 
> > > But beware of k3b's KDE dependencies.  
> > 
> > I was going to mention that, though it varies according to what you
> > have already. I like k3b, and also like konqueror as a backup
> > browser, so on my desktop machine I'm willing to tolerate the KDE
> > stuff that comes with them that I never use.  
> 
> Hopefully those KDE dependencies didn't "enhance" your system with a
> few resource hogging daemons. A "ps ax" check could be helpful there.

No, that's just Firefox, as usual...

-- 
Joe