Re: [lxc-users] TTY issue

[Marat Khalili]

On 21/11/17 15:07, Saint Michael wrote:

Thanks for the solution. It works indeed.
Just out of curiosity, how did you find this out? I googled it far and 
wide and there was nothing available.


The autodev part, I needed it in order to make qemu networking work in a 
container via /dev/net/tun device which is missing by default. I did not 
invent it, found somewhere in Google, probably here: 
https://serverfault.com/questions/429461/no-tun-device-in-lxc-guest-for-openvpn 
. It just executes specified command(s) during /dev population, nothing 
magical; you can execute same command in the container later if you can 
afford to defer your mounts or whatever uses the created device.


/dev/fuse is more interesting, I was trying to make snapd work in an LXC 
container, still not very successful in that. You can read more about 
this effort in the discussion on the bottom of 
https://bugs.launchpad.net/snappy/+bug/1628289


--

With Best Regards,
Marat Khalili

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

Thanks for the solution. It works indeed.
Just out of curiosity, how did you find this out? I googled it far and wide
and there was nothing available.


On Sat, Nov 18, 2017 at 9:13 AM, Marat Khalili  wrote:

> On 18/11/17 17:10, Saint Michael wrote:
>
> Yes, of course. It works but only if autodev=0
> That is the issue.
>
>
> Even as:
>
> lxc.hook.autodev = sh -c 'mknod ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229'
>
> ?
>
>
> --
>
> With Best Regards,
> Marat Khalili
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

I don't control the server side. They upgraded to Secure FTP a few days ago.


On Mon, Nov 20, 2017 at 11:56 AM, Andrey Repin  wrote:

> Greetings, Saint Michael!
>
> > How do you rsync over SSH when all you have is a Plain Old FTP server to
> connect to?
> > Maybe there is something I need to learn.
>
> Remove FTP, it's insecure by definition, cumbersome in setup and not
> usable in
> general.
>
>
> --
> With best regards,
> Andrey Repin
> Monday, November 20, 2017 19:56:05
>
> Sorry for my terrible english...
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Andrey Repin]

Greetings, Saint Michael!

> How do you rsync over SSH when all you have is a Plain Old FTP server to 
> connect to?
> Maybe there is something I need to learn.

Remove FTP, it's insecure by definition, cumbersome in setup and not usable in
general.


-- 
With best regards,
Andrey Repin
Monday, November 20, 2017 19:56:05

Sorry for my terrible english...

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Ron Kelley]

> On Nov 20, 2017, at 1:58 AM, Marat Khalili  wrote:
> 
> On 19/11/17 22:45, Ron Kelley wrote:
>> In all seriousness, I just ran some tests on my servers to see if SSH is 
>> still the bottleneck on rsync.  These servers have dual 10G NICs (linux 
>> bond), 3.6GHz CPU, and 32G RAM.  I found some interesting data points:
>> 
>> * Running the command "pv /dev/zero | ssh $REMOTE_SERVER 'cat > /dev/null’” 
>> I was able to get about 235MB/sec between two servers with ssh pegged at 
>> 100% CPU usage. [...]
>> In the end, rsync over NFS (using 10G networking) is much faster than rsync 
>> using SSH keys in my environment.  Maybe your environment is different or 
>> you use different ciphers?
> 
> Very good data points. I agree that you can saturate ssh if you have 10G 
> network connection and either SSDs or some expensive HDD arrays on both sides 
> and some sequential data to transfer. If you don't have any of listed items, 
> ssh does not slow down things.
Agreed as well.  In fact, I was a little surprised to see a “typical” server 
run over 200MB/sec in SSH traffic.  But, to be honest, it has been a while 
since I have done any sort of ssh speed tests.


> As for not trusting the LAN with unencrypted traffic, I would argue either 
> the security policies are not well enforced or the server uses insecure NFS 
> mount options.  I have no reason not to trust my LAN.
> I was just afraid that someone reading your post would copy-paste your 
> configuration to use over less secure LAN or even WAN. (I admit this is not a 
> big problem for original poster since FTP is not much better in this regard.)
Ah, yes, understood.  If someone is concerned about unencrypted rsync traffic, 
you could add tighter security options to the rsyncd.conf file and/or use NFSv4 
with higher security.


> 
> 
> --
> 
> With Best Regards,
> Marat Khalili
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Marat Khalili]

On 19/11/17 22:45, Ron Kelley wrote:

In all seriousness, I just ran some tests on my servers to see if SSH is still 
the bottleneck on rsync.  These servers have dual 10G NICs (linux bond), 3.6GHz 
CPU, and 32G RAM.  I found some interesting data points:

* Running the command "pv /dev/zero | ssh $REMOTE_SERVER 'cat > /dev/null’” I 
was able to get about 235MB/sec between two servers with ssh pegged at 100% CPU usage. 
[...]
In the end, rsync over NFS (using 10G networking) is much faster than rsync 
using SSH keys in my environment.  Maybe your environment is different or you 
use different ciphers?


Very good data points. I agree that you can saturate ssh if you have 10G 
network connection and either SSDs or some expensive HDD arrays on both 
sides and some sequential data to transfer. If you don't have any of 
listed items, ssh does not slow down things.




As for not trusting the LAN with unencrypted traffic, I would argue either the 
security policies are not well enforced or the server uses insecure NFS mount 
options.  I have no reason not to trust my LAN.
I was just afraid that someone reading your post would copy-paste your 
configuration to use over less secure LAN or even WAN. (I admit this is 
not a big problem for original poster since FTP is not much better in 
this regard.)



--

With Best Regards,
Marat Khalili

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

I have yet to connect to the new secure server.

On Sun, Nov 19, 2017 at 3:40 PM, jjs - mainphrame 
wrote:

> Curious - BTW there are 3 completely different protocols, all referred to
> as "sftp" - hopefully they're using the one that listens on port 22.
>
> J
>
> On Sun, Nov 19, 2017 at 11:27 AM, Saint Michael  wrote:
>
>> Last wee they upgraded to SFTP
>> It is one of those Federal Agencies that are behind in times.
>>
>>
>>
>>
>>
>>
>> On Sun, Nov 19, 2017 at 2:14 PM, Ron Kelley  wrote:
>>
>>> Maybe I missed something here, but you have a government system that
>>> allows FTP but not NFS?
>>>
>>>
>>>
>>> > On Nov 19, 2017, at 10:17 AM, Saint Michael  wrote:
>>> >
>>> > The server is at a the government. I would go to jail.
>>> > But thanks for the input.
>>> >
>>> > On Sun, Nov 19, 2017 at 8:03 AM, Ron Kelley 
>>> wrote:
>>> > Can you install an rsync daemon on the server side?  If so, simply
>>> create /etc/rsyncd.conf file with this:
>>> >
>>> > [BACKUP]
>>> > comment = Allow RW access for backups
>>> > path = /usr/local/backup_dir
>>> > uid = root
>>> > hosts allow = 192.168.1.46, 192.168.1.47
>>> > read only = yes
>>> >
>>> >
>>> > Next, on each of your remote clients, simply run rsync via cron job to
>>> your server.   Something like this:
>>> >
>>> > /usr/bin/rsync -arv / root@192.168.1.10::BACKUP/192.
>>> 168.1.46/
>>> >
>>> > The above assumes your server IP is 192.168.1.10 and your client IP is
>>> 192.168.1.46.  Also, note the trailing slash (/) on the second rsync
>>> argument.  It ensures the files get put into the right directory.
>>> >
>>> > I run rsync scripts each night on lots of client machines
>>> (specifically LXD containers running wordpress) to a central backup
>>> server.  It works great.
>>> >
>>> >
>>> > BTW: I don’t know if I could say rsync over a network mount is the
>>> worst possible solution ever.  I have used rsync for a long time and using
>>> a variety of network connections (rsync daemon, nfs, rsync via ssh).  My
>>> experience has shown rsync over ssh is by far the slowest because of the
>>> ssh cipher.  Rsync over nfs mount is very fast - almost as fast as a local
>>> copy.
>>> >
>>> > -Ron
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > > On Nov 18, 2017, at 9:37 PM, Saint Michael 
>>> wrote:
>>> > >
>>> > > How do you rsync over SSH when all you have is a Plain Old FTP
>>> server to connect to?
>>> > > Maybe there is something I need to learn.
>>> > >
>>> > > On Sat, Nov 18, 2017 at 5:08 PM, Andrey Repin 
>>> wrote:
>>> > > Greetings, Saint Michael!
>>> > >
>>> > > > I need to do an rsync of hundreds of files very morning. The least
>>> complex
>>> > > > way to achieve that is to do an rsync with some parameters that
>>> narrow down what files I need.
>>> > > > Is there a better way?
>>> > >
>>> > > rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
>>> > > Use normal rsync over SSH, it will be much faster, even if you do
>>> checksum
>>> > > syncs.
>>> > >
>>> > >
>>> > > --
>>> > > With best regards,
>>> > > Andrey Repin
>>> > > Sunday, November 19, 2017 01:07:34
>>> > >
>>> > > Sorry for my terrible english...
>>> > >
>>> > > ___
>>> > > lxc-users mailing list
>>> > > lxc-users@lists.linuxcontainers.org
>>> > > http://lists.linuxcontainers.org/listinfo/lxc-users
>>> > >
>>> > > ___
>>> > > lxc-users mailing list
>>> > > lxc-users@lists.linuxcontainers.org
>>> > > http://lists.linuxcontainers.org/listinfo/lxc-users
>>> >
>>> > ___
>>> > lxc-users mailing list
>>> > lxc-users@lists.linuxcontainers.org
>>> > http://lists.linuxcontainers.org/listinfo/lxc-users
>>> >
>>> > ___
>>> > lxc-users mailing list
>>> > lxc-users@lists.linuxcontainers.org
>>> > http://lists.linuxcontainers.org/listinfo/lxc-users
>>>
>>> ___
>>> lxc-users mailing list
>>> lxc-users@lists.linuxcontainers.org
>>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>>
>>
>>
>> ___
>> lxc-users mailing list
>> lxc-users@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[jjs - mainphrame]

Curious - BTW there are 3 completely different protocols, all referred to
as "sftp" - hopefully they're using the one that listens on port 22.

J

On Sun, Nov 19, 2017 at 11:27 AM, Saint Michael  wrote:

> Last wee they upgraded to SFTP
> It is one of those Federal Agencies that are behind in times.
>
>
>
>
>
>
> On Sun, Nov 19, 2017 at 2:14 PM, Ron Kelley  wrote:
>
>> Maybe I missed something here, but you have a government system that
>> allows FTP but not NFS?
>>
>>
>>
>> > On Nov 19, 2017, at 10:17 AM, Saint Michael  wrote:
>> >
>> > The server is at a the government. I would go to jail.
>> > But thanks for the input.
>> >
>> > On Sun, Nov 19, 2017 at 8:03 AM, Ron Kelley 
>> wrote:
>> > Can you install an rsync daemon on the server side?  If so, simply
>> create /etc/rsyncd.conf file with this:
>> >
>> > [BACKUP]
>> > comment = Allow RW access for backups
>> > path = /usr/local/backup_dir
>> > uid = root
>> > hosts allow = 192.168.1.46, 192.168.1.47
>> > read only = yes
>> >
>> >
>> > Next, on each of your remote clients, simply run rsync via cron job to
>> your server.   Something like this:
>> >
>> > /usr/bin/rsync -arv / root@192.168.1.10::BACKUP/192.
>> 168.1.46/
>> >
>> > The above assumes your server IP is 192.168.1.10 and your client IP is
>> 192.168.1.46.  Also, note the trailing slash (/) on the second rsync
>> argument.  It ensures the files get put into the right directory.
>> >
>> > I run rsync scripts each night on lots of client machines (specifically
>> LXD containers running wordpress) to a central backup server.  It works
>> great.
>> >
>> >
>> > BTW: I don’t know if I could say rsync over a network mount is the
>> worst possible solution ever.  I have used rsync for a long time and using
>> a variety of network connections (rsync daemon, nfs, rsync via ssh).  My
>> experience has shown rsync over ssh is by far the slowest because of the
>> ssh cipher.  Rsync over nfs mount is very fast - almost as fast as a local
>> copy.
>> >
>> > -Ron
>> >
>> >
>> >
>> >
>> >
>> >
>> > > On Nov 18, 2017, at 9:37 PM, Saint Michael  wrote:
>> > >
>> > > How do you rsync over SSH when all you have is a Plain Old FTP server
>> to connect to?
>> > > Maybe there is something I need to learn.
>> > >
>> > > On Sat, Nov 18, 2017 at 5:08 PM, Andrey Repin 
>> wrote:
>> > > Greetings, Saint Michael!
>> > >
>> > > > I need to do an rsync of hundreds of files very morning. The least
>> complex
>> > > > way to achieve that is to do an rsync with some parameters that
>> narrow down what files I need.
>> > > > Is there a better way?
>> > >
>> > > rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
>> > > Use normal rsync over SSH, it will be much faster, even if you do
>> checksum
>> > > syncs.
>> > >
>> > >
>> > > --
>> > > With best regards,
>> > > Andrey Repin
>> > > Sunday, November 19, 2017 01:07:34
>> > >
>> > > Sorry for my terrible english...
>> > >
>> > > ___
>> > > lxc-users mailing list
>> > > lxc-users@lists.linuxcontainers.org
>> > > http://lists.linuxcontainers.org/listinfo/lxc-users
>> > >
>> > > ___
>> > > lxc-users mailing list
>> > > lxc-users@lists.linuxcontainers.org
>> > > http://lists.linuxcontainers.org/listinfo/lxc-users
>> >
>> > ___
>> > lxc-users mailing list
>> > lxc-users@lists.linuxcontainers.org
>> > http://lists.linuxcontainers.org/listinfo/lxc-users
>> >
>> > ___
>> > lxc-users mailing list
>> > lxc-users@lists.linuxcontainers.org
>> > http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>> ___
>> lxc-users mailing list
>> lxc-users@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Ron Kelley]

 I just checked my calendar, and it says November, 19, 2017.  So, I am 
going to say, 21st century! 

In all seriousness, I just ran some tests on my servers to see if SSH is still 
the bottleneck on rsync.  These servers have dual 10G NICs (linux bond), 3.6GHz 
CPU, and 32G RAM.  I found some interesting data points:

* Running the command "pv /dev/zero | ssh $REMOTE_SERVER 'cat > /dev/null’” I 
was able to get about 235MB/sec between two servers with ssh pegged at 100% CPU 
usage. 

* I mounted an NFS share from one server to the other and was able to hit 
450MB/sec via rsync across an NFS mount (rsync pegged at 100% CPU).  

* I ran the command “rsync --progress root@:/export/tmp/file1 
/mnt/ramdisk/file1” gave me 130MB/sec with sshd pegged at 100% CPU and rsync at 
22% CPU.


In the end, rsync over NFS (using 10G networking) is much faster than rsync 
using SSH keys in my environment.  Maybe your environment is different or you 
use different ciphers?



As for not trusting the LAN with unencrypted traffic, I would argue either the 
security policies are not well enforced or the server uses insecure NFS mount 
options.  I have no reason not to trust my LAN.

-Ron





> On Nov 19, 2017, at 10:39 AM, Marat Khalili  wrote:
> 
>> My experience has shown rsync over ssh is by far the slowest because of the 
>> ssh cipher. 
> 
> What century is this experience from? Any modern hardware can encrypt at IO 
> speed several times over. Even LAN, on the other hand, cannot be trusted with 
> unencrypted data.
> -- 
> 
> With Best Regards,
> Marat Khalili
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

Last wee they upgraded to SFTP
It is one of those Federal Agencies that are behind in times.






On Sun, Nov 19, 2017 at 2:14 PM, Ron Kelley  wrote:

> Maybe I missed something here, but you have a government system that
> allows FTP but not NFS?
>
>
>
> > On Nov 19, 2017, at 10:17 AM, Saint Michael  wrote:
> >
> > The server is at a the government. I would go to jail.
> > But thanks for the input.
> >
> > On Sun, Nov 19, 2017 at 8:03 AM, Ron Kelley 
> wrote:
> > Can you install an rsync daemon on the server side?  If so, simply
> create /etc/rsyncd.conf file with this:
> >
> > [BACKUP]
> > comment = Allow RW access for backups
> > path = /usr/local/backup_dir
> > uid = root
> > hosts allow = 192.168.1.46, 192.168.1.47
> > read only = yes
> >
> >
> > Next, on each of your remote clients, simply run rsync via cron job to
> your server.   Something like this:
> >
> > /usr/bin/rsync -arv / root@192.168.1.10::BACKUP/192.168.1.46/
> >
> > The above assumes your server IP is 192.168.1.10 and your client IP is
> 192.168.1.46.  Also, note the trailing slash (/) on the second rsync
> argument.  It ensures the files get put into the right directory.
> >
> > I run rsync scripts each night on lots of client machines (specifically
> LXD containers running wordpress) to a central backup server.  It works
> great.
> >
> >
> > BTW: I don’t know if I could say rsync over a network mount is the worst
> possible solution ever.  I have used rsync for a long time and using a
> variety of network connections (rsync daemon, nfs, rsync via ssh).  My
> experience has shown rsync over ssh is by far the slowest because of the
> ssh cipher.  Rsync over nfs mount is very fast - almost as fast as a local
> copy.
> >
> > -Ron
> >
> >
> >
> >
> >
> >
> > > On Nov 18, 2017, at 9:37 PM, Saint Michael  wrote:
> > >
> > > How do you rsync over SSH when all you have is a Plain Old FTP server
> to connect to?
> > > Maybe there is something I need to learn.
> > >
> > > On Sat, Nov 18, 2017 at 5:08 PM, Andrey Repin 
> wrote:
> > > Greetings, Saint Michael!
> > >
> > > > I need to do an rsync of hundreds of files very morning. The least
> complex
> > > > way to achieve that is to do an rsync with some parameters that
> narrow down what files I need.
> > > > Is there a better way?
> > >
> > > rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
> > > Use normal rsync over SSH, it will be much faster, even if you do
> checksum
> > > syncs.
> > >
> > >
> > > --
> > > With best regards,
> > > Andrey Repin
> > > Sunday, November 19, 2017 01:07:34
> > >
> > > Sorry for my terrible english...
> > >
> > > ___
> > > lxc-users mailing list
> > > lxc-users@lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> > >
> > > ___
> > > lxc-users mailing list
> > > lxc-users@lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Ron Kelley]

Maybe I missed something here, but you have a government system that allows FTP 
but not NFS?



> On Nov 19, 2017, at 10:17 AM, Saint Michael  wrote:
> 
> The server is at a the government. I would go to jail.
> But thanks for the input.
> 
> On Sun, Nov 19, 2017 at 8:03 AM, Ron Kelley  wrote:
> Can you install an rsync daemon on the server side?  If so, simply create 
> /etc/rsyncd.conf file with this:
> 
> [BACKUP]
> comment = Allow RW access for backups
> path = /usr/local/backup_dir
> uid = root
> hosts allow = 192.168.1.46, 192.168.1.47
> read only = yes
> 
> 
> Next, on each of your remote clients, simply run rsync via cron job to your 
> server.   Something like this:
> 
> /usr/bin/rsync -arv / root@192.168.1.10::BACKUP/192.168.1.46/
> 
> The above assumes your server IP is 192.168.1.10 and your client IP is 
> 192.168.1.46.  Also, note the trailing slash (/) on the second rsync 
> argument.  It ensures the files get put into the right directory.
> 
> I run rsync scripts each night on lots of client machines (specifically LXD 
> containers running wordpress) to a central backup server.  It works great.
> 
> 
> BTW: I don’t know if I could say rsync over a network mount is the worst 
> possible solution ever.  I have used rsync for a long time and using a 
> variety of network connections (rsync daemon, nfs, rsync via ssh).  My 
> experience has shown rsync over ssh is by far the slowest because of the ssh 
> cipher.  Rsync over nfs mount is very fast - almost as fast as a local copy.
> 
> -Ron
> 
> 
> 
> 
> 
> 
> > On Nov 18, 2017, at 9:37 PM, Saint Michael  wrote:
> >
> > How do you rsync over SSH when all you have is a Plain Old FTP server to 
> > connect to?
> > Maybe there is something I need to learn.
> >
> > On Sat, Nov 18, 2017 at 5:08 PM, Andrey Repin  wrote:
> > Greetings, Saint Michael!
> >
> > > I need to do an rsync of hundreds of files very morning. The least complex
> > > way to achieve that is to do an rsync with some parameters that narrow 
> > > down what files I need.
> > > Is there a better way?
> >
> > rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
> > Use normal rsync over SSH, it will be much faster, even if you do checksum
> > syncs.
> >
> >
> > --
> > With best regards,
> > Andrey Repin
> > Sunday, November 19, 2017 01:07:34
> >
> > Sorry for my terrible english...
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Marat Khalili]

> My experience has shown rsync over ssh is by far the slowest because of the 
> ssh cipher. 

What century is this experience from? Any modern hardware can encrypt at IO 
speed several times over. Even LAN, on the other hand, cannot be trusted with 
unencrypted data.
-- 

With Best Regards,
Marat Khalili
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

The server is at a the government. I would go to jail.
But thanks for the input.

On Sun, Nov 19, 2017 at 8:03 AM, Ron Kelley  wrote:

> Can you install an rsync daemon on the server side?  If so, simply create
> /etc/rsyncd.conf file with this:
>
> [BACKUP]
> comment = Allow RW access for backups
> path = /usr/local/backup_dir
> uid = root
> hosts allow = 192.168.1.46, 192.168.1.47
> read only = yes
>
>
> Next, on each of your remote clients, simply run rsync via cron job to
> your server.   Something like this:
>
> /usr/bin/rsync -arv / root@192.168.1.10::BACKUP/192.168.1.46/
>
> The above assumes your server IP is 192.168.1.10 and your client IP is
> 192.168.1.46.  Also, note the trailing slash (/) on the second rsync
> argument.  It ensures the files get put into the right directory.
>
> I run rsync scripts each night on lots of client machines (specifically
> LXD containers running wordpress) to a central backup server.  It works
> great.
>
>
> BTW: I don’t know if I could say rsync over a network mount is the worst
> possible solution ever.  I have used rsync for a long time and using a
> variety of network connections (rsync daemon, nfs, rsync via ssh).  My
> experience has shown rsync over ssh is by far the slowest because of the
> ssh cipher.  Rsync over nfs mount is very fast - almost as fast as a local
> copy.
>
> -Ron
>
>
>
>
>
>
> > On Nov 18, 2017, at 9:37 PM, Saint Michael  wrote:
> >
> > How do you rsync over SSH when all you have is a Plain Old FTP server to
> connect to?
> > Maybe there is something I need to learn.
> >
> > On Sat, Nov 18, 2017 at 5:08 PM, Andrey Repin 
> wrote:
> > Greetings, Saint Michael!
> >
> > > I need to do an rsync of hundreds of files very morning. The least
> complex
> > > way to achieve that is to do an rsync with some parameters that narrow
> down what files I need.
> > > Is there a better way?
> >
> > rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
> > Use normal rsync over SSH, it will be much faster, even if you do
> checksum
> > syncs.
> >
> >
> > --
> > With best regards,
> > Andrey Repin
> > Sunday, November 19, 2017 01:07:34
> >
> > Sorry for my terrible english...
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Ron Kelley]

Can you install an rsync daemon on the server side?  If so, simply create 
/etc/rsyncd.conf file with this:

[BACKUP]
comment = Allow RW access for backups
path = /usr/local/backup_dir
uid = root
hosts allow = 192.168.1.46, 192.168.1.47
read only = yes


Next, on each of your remote clients, simply run rsync via cron job to your 
server.   Something like this:

/usr/bin/rsync -arv / root@192.168.1.10::BACKUP/192.168.1.46/

The above assumes your server IP is 192.168.1.10 and your client IP is 
192.168.1.46.  Also, note the trailing slash (/) on the second rsync argument.  
It ensures the files get put into the right directory.

I run rsync scripts each night on lots of client machines (specifically LXD 
containers running wordpress) to a central backup server.  It works great.


BTW: I don’t know if I could say rsync over a network mount is the worst 
possible solution ever.  I have used rsync for a long time and using a variety 
of network connections (rsync daemon, nfs, rsync via ssh).  My experience has 
shown rsync over ssh is by far the slowest because of the ssh cipher.  Rsync 
over nfs mount is very fast - almost as fast as a local copy.

-Ron






> On Nov 18, 2017, at 9:37 PM, Saint Michael  wrote:
> 
> How do you rsync over SSH when all you have is a Plain Old FTP server to 
> connect to?
> Maybe there is something I need to learn.
> 
> On Sat, Nov 18, 2017 at 5:08 PM, Andrey Repin  wrote:
> Greetings, Saint Michael!
> 
> > I need to do an rsync of hundreds of files very morning. The least complex
> > way to achieve that is to do an rsync with some parameters that narrow down 
> > what files I need.
> > Is there a better way?
> 
> rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
> Use normal rsync over SSH, it will be much faster, even if you do checksum
> syncs.
> 
> 
> --
> With best regards,
> Andrey Repin
> Sunday, November 19, 2017 01:07:34
> 
> Sorry for my terrible english...
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

How do you rsync over SSH when all you have is a Plain Old FTP server to
connect to?
Maybe there is something I need to learn.

On Sat, Nov 18, 2017 at 5:08 PM, Andrey Repin  wrote:

> Greetings, Saint Michael!
>
> > I need to do an rsync of hundreds of files very morning. The least
> complex
> > way to achieve that is to do an rsync with some parameters that narrow
> down what files I need.
> > Is there a better way?
>
> rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
> Use normal rsync over SSH, it will be much faster, even if you do checksum
> syncs.
>
>
> --
> With best regards,
> Andrey Repin
> Sunday, November 19, 2017 01:07:34
>
> Sorry for my terrible english...
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Andrey Repin]

Greetings, Saint Michael!

> I need to do an rsync of hundreds of files very morning. The least complex
> way to achieve that is to do an rsync with some parameters that narrow down 
> what files I need.
> Is there a better way?

rsync over a network mount is the WORST POSSIBLE SOLUTION EVER.
Use normal rsync over SSH, it will be much faster, even if you do checksum
syncs.


-- 
With best regards,
Andrey Repin
Sunday, November 19, 2017 01:07:34

Sorry for my terrible english...

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

Let me try that

On Sat, Nov 18, 2017 at 9:13 AM, Marat Khalili  wrote:

> On 18/11/17 17:10, Saint Michael wrote:
>
> Yes, of course. It works but only if autodev=0
> That is the issue.
>
>
> Even as:
>
> lxc.hook.autodev = sh -c 'mknod ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229'
>
> ?
>
>
> --
>
> With Best Regards,
> Marat Khalili
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Marat Khalili]

On 18/11/17 17:10, Saint Michael wrote:

Yes, of course. It works but only if autodev=0
That is the issue.


Even as:


lxc.hook.autodev = sh -c 'mknod ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229'

?


--

With Best Regards,
Marat Khalili
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

Yes, of course. It works but only if autodev=0
That is the issue.


On Sat, Nov 18, 2017 at 9:06 AM, Marat Khalili  wrote:

> On 16/11/17 18:50, Saint Michael wrote:
>
> The issue is with fuse, that is why I keep
> lxc.autodev=0
> if I do not, if I set it to 1, then fuse does not mount inside a
> container. I need fuse, for I mount an FTP server inside the container.
> So I am caught between a rock and a hard place.
> I akready asked about this contradiction on the LXC developers list.
>
> BTW, did you try:
>
> mknod /dev/fuse c 10 229
>
> ?
>
> --
>
> With Best Regards,
> Marat Khalili
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Marat Khalili]

On 16/11/17 18:50, Saint Michael wrote:

The issue is with fuse, that is why I keep
lxc.autodev=0
if I do not, if I set it to 1, then fuse does not mount inside a 
container. I need fuse, for I mount an FTP server inside the container.

So I am caught between a rock and a hard place.
I akready asked about this contradiction on the LXC developers list.

BTW, did you try:

mknod /dev/fuse c 10 229

?

--

With Best Regards,
Marat Khalili
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Marat Khalili]

On 18/11/17 14:46, Saint Michael wrote:
I need to do an rsync of hundreds of files very morning. The least 
complex way to achieve that is to do an rsync with some parameters 
that narrow down what files I need.

Is there a better way?

On Fri, Nov 17, 2017 at 11:43 PM, Andrey Repin > wrote:


Was there the need for it? Really?
I feel like you've dug the grave for yourself with this config.



I understand the need, but not the solution. I also have some remote 
mounts (SMB, WebDAV...) that I'd like to rsync but don't want to mount 
on host. However, I my case I had to create "true" kvm-based VM for it. 
I'd like to learn a clean way to do it in LXC container without problems 
like OP encountered.



--

With Best Regards,
Marat Khalili

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

I need to do an rsync of hundreds of files very morning. The least complex
way to achieve that is to do an rsync with some parameters that narrow down
what files I need.
Is there a better way?

On Fri, Nov 17, 2017 at 11:43 PM, Andrey Repin  wrote:

> Greetings, Saint Michael!
>
> > lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
> > lxc.mount.entry = sysfs sys sysfs defaults  0 0
> > lxc.mount.entry = /cdr cdr none bind 0 0
> > lxc.mount.auto = cgroup:mixed
> > lxc.tty = 10
> > lxc.pts = 1024
> > lxc.cgroup.devices.deny = a
> > lxc.cgroup.devices.allow = c 1:3 rwm
> > lxc.cgroup.devices.allow = c 1:5 rwm
> > lxc.cgroup.devices.allow = c 5:1 rwm
> > lxc.cgroup.devices.allow = c 5:0 rwm
> > lxc.cgroup.devices.allow = c 4:0 rwm
> > lxc.cgroup.devices.allow = c 4:1 rwm
> > lxc.cgroup.devices.allow = c 1:9 rwm
> > lxc.cgroup.devices.allow = c 1:8 rwm
> > lxc.cgroup.devices.allow = c 136:* rwm
> > lxc.cgroup.devices.allow = c 5:2 rwm
> > lxc.cgroup.devices.allow = c 254:0 rwm
> > lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
> > lxc.cgroup.devices.allow = b 7:* rwm# loop*
> > lxc.cgroup.devices.allow = c 10:229 rwm #fuse
> > lxc.autodev = 0
> > lxc.aa_profile = unconfined
> > lxc.cap.drop=
> > lxc.network.type = phys
> > lxc.network.flags = up
> > lxc.network.link = eth6
> > lxc.network.name = eth0
> > lxc.network.ipv4 = 0.0.0.0/27
> > lxc.network.type = macvlan
> > lxc.network.flags = up
> > lxc.network.link = eth3
> > lxc.network.name = eth1
> > lxc.network.macvlan.mode = bridge
> > lxc.network.ipv4 = 0.0.0.0/24
>
> > lxc.start.auto = 1
> > lxc.start.delay = 5
> > lxc.start.order = 0
> > lxc.rootfs = /data/iplinkcdr/rootfs
> > lxc.rootfs.backend = dir
> > lxc.utsname = iplinkcdr
>
> Was there the need for it? Really?
> I feel like you've dug the grave for yourself with this config.
>
>
> --
> With best regards,
> Andrey Repin
> Saturday, November 18, 2017 07:42:06
>
> Sorry for my terrible english...
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Andrey Repin]

Greetings, Saint Michael!

> lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
> lxc.mount.entry = sysfs sys sysfs defaults  0 0
> lxc.mount.entry = /cdr cdr none bind 0 0
> lxc.mount.auto = cgroup:mixed
> lxc.tty = 10
> lxc.pts = 1024
> lxc.cgroup.devices.deny = a
> lxc.cgroup.devices.allow = c 1:3 rwm
> lxc.cgroup.devices.allow = c 1:5 rwm
> lxc.cgroup.devices.allow = c 5:1 rwm
> lxc.cgroup.devices.allow = c 5:0 rwm
> lxc.cgroup.devices.allow = c 4:0 rwm
> lxc.cgroup.devices.allow = c 4:1 rwm
> lxc.cgroup.devices.allow = c 1:9 rwm
> lxc.cgroup.devices.allow = c 1:8 rwm
> lxc.cgroup.devices.allow = c 136:* rwm
> lxc.cgroup.devices.allow = c 5:2 rwm
> lxc.cgroup.devices.allow = c 254:0 rwm
> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
> lxc.cgroup.devices.allow = b 7:* rwm    # loop*
> lxc.cgroup.devices.allow = c 10:229 rwm #fuse
> lxc.autodev = 0
> lxc.aa_profile = unconfined
> lxc.cap.drop=
> lxc.network.type = phys
> lxc.network.flags = up
> lxc.network.link = eth6
> lxc.network.name = eth0
> lxc.network.ipv4 = 0.0.0.0/27
> lxc.network.type = macvlan
> lxc.network.flags = up
> lxc.network.link = eth3
> lxc.network.name = eth1
> lxc.network.macvlan.mode = bridge
> lxc.network.ipv4 = 0.0.0.0/24

> lxc.start.auto = 1
> lxc.start.delay = 5
> lxc.start.order = 0
> lxc.rootfs = /data/iplinkcdr/rootfs
> lxc.rootfs.backend = dir
> lxc.utsname = iplinkcdr

Was there the need for it? Really?
I feel like you've dug the grave for yourself with this config.


-- 
With best regards,
Andrey Repin
Saturday, November 18, 2017 07:42:06

Sorry for my terrible english...
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Andrey Repin]

Greetings, Saint Michael!

> The issue is with fuse, that is why I keep 
> lxc.autodev=0
> if I do not, if I set it to 1, then fuse does not mount inside a container.
> I need fuse, for I mount an FTP server inside the container.
> So I am caught between a rock and a hard place.
> I akready asked about this contradiction on the LXC developers list.

I'd strongly suggest to rethink your needs.
WHY do you mount an FTP server, in first place?


-- 
With best regards,
Andrey Repin
Saturday, November 18, 2017 07:44:00

Sorry for my terrible english...
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Fajar A. Nugraha]

On Thu, Nov 16, 2017 at 10:50 PM, Saint Michael  wrote:

> The issue is with fuse, that is why I keep
> lxc.autodev=0
> if I do not, if I set it to 1, then fuse does not mount inside a
> container. I need fuse, for I mount an FTP server inside the container.
> So I am caught between a rock and a hard place.
> I akready asked about this contradiction on the LXC developers list.
>
>

I use fuse (for clipboard and file copy/paste support on xrdp) on
privileged lxd container. Works fine.
Can't comment more about the old lxc though, since all my newer systems are
using lxd.

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

The issue is with fuse, that is why I keep
lxc.autodev=0
if I do not, if I set it to 1, then fuse does not mount inside a container.
I need fuse, for I mount an FTP server inside the container.
So I am caught between a rock and a hard place.
I akready asked about this contradiction on the LXC developers list.



On Thu, Nov 16, 2017 at 10:45 AM, Fajar A. Nugraha  wrote:

> On Thu, Nov 16, 2017 at 10:04 PM, Saint Michael  wrote:
>
>> I missfired.
>> But I found the culprit, it is
>> lxc.autodev = 0
>>
>> if I use
>> lxc.autodev = 1
>> the issue does not happens
>> Can somebodu shed any light on the ramifications of this?
>>
>
> Try https://linuxcontainers.org/lxc/manpages/man5/lxc.
> container.conf.5.html , look for 'CONSOLE DEVICES' and 'lxc.autodev'.
>
>
>> Some additional information: I use fuse inside my containers.
>>
>>
> One the reasons I suggested using lxd, is that with the default lxd setup,
> you'd be less-likely to shoot-yourself-in-the-foot.
>
> Fuse complicates things a little, since you need a privileged container to
> use it. But even when using privileged container, the default lxd setup
> (using templates) is still good-enough to prevent common problems created
> by host-container interaction.
>
>
> --
> Fajar
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Fajar A. Nugraha]

On Thu, Nov 16, 2017 at 10:04 PM, Saint Michael  wrote:

> I missfired.
> But I found the culprit, it is
> lxc.autodev = 0
>
> if I use
> lxc.autodev = 1
> the issue does not happens
> Can somebodu shed any light on the ramifications of this?
>

Try https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html
, look for 'CONSOLE DEVICES' and 'lxc.autodev'.


> Some additional information: I use fuse inside my containers.
>
>
One the reasons I suggested using lxd, is that with the default lxd setup,
you'd be less-likely to shoot-yourself-in-the-foot.

Fuse complicates things a little, since you need a privileged container to
use it. But even when using privileged container, the default lxd setup
(using templates) is still good-enough to prevent common problems created
by host-container interaction.


-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

I missfired.
But I found the culprit, it is
lxc.autodev = 0

if I use
lxc.autodev = 1
the issue does not happens
Can somebodu shed any light on the ramifications of this?
Some additional information: I use fuse inside my containers.

Philip



On Thu, Nov 16, 2017 at 9:52 AM, Saint Michael  wrote:

> THAT WORKED
> But the new key is
> lxc.tty.dir = lxc
>
>
> On Thu, Nov 16, 2017 at 9:32 AM, Marat Khalili  wrote:
>
>> On 16/11/17 14:58, Saint Michael wrote:
>>
>> lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
>> lxc.mount.entry = sysfs sys sysfs defaults  0 0
>> lxc.mount.entry = /cdr cdr none bind 0 0
>> lxc.mount.auto = cgroup:mixed
>> lxc.tty = 10
>> lxc.pts = 1024
>> lxc.cgroup.devices.deny = a
>> lxc.cgroup.devices.allow = c 1:3 rwm
>> lxc.cgroup.devices.allow = c 1:5 rwm
>> lxc.cgroup.devices.allow = c 5:1 rwm
>> lxc.cgroup.devices.allow = c 5:0 rwm
>> lxc.cgroup.devices.allow = c 4:0 rwm
>> lxc.cgroup.devices.allow = c 4:1 rwm
>> lxc.cgroup.devices.allow = c 1:9 rwm
>> lxc.cgroup.devices.allow = c 1:8 rwm
>> lxc.cgroup.devices.allow = c 136:* rwm
>> lxc.cgroup.devices.allow = c 5:2 rwm
>> lxc.cgroup.devices.allow = c 254:0 rwm
>> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
>> lxc.cgroup.devices.allow = b 7:* rwm# loop*
>> lxc.cgroup.devices.allow = c 10:229 rwm #fuse
>> lxc.autodev = 0
>> lxc.aa_profile = unconfined
>> lxc.cap.drop=
>> lxc.network.type = phys
>> lxc.network.flags = up
>> lxc.network.link = eth6
>> lxc.network.name = eth0
>> lxc.network.ipv4 = 0.0.0.0/27
>> lxc.network.type = macvlan
>> lxc.network.flags = up
>> lxc.network.link = eth3
>> lxc.network.name = eth1
>> lxc.network.macvlan.mode = bridge
>> lxc.network.ipv4 = 0.0.0.0/24
>>
>> lxc.start.auto = 1
>> lxc.start.delay = 5
>> lxc.start.order = 0
>> lxc.rootfs = /data/iplinkcdr/rootfs
>> lxc.rootfs.backend = dir
>> lxc.utsname = iplinkcdr
>>
>>
>> It does not look as config created by lxc-create. Does same thing happen
>> if you use `lxc-create -t download`?
>>
>> Looking at your config, I most notably don't see `lxc.devttydir = lxc`.
>> Although according to man it should not directly cause effect you
>> described, but I'd still try to add it and see. `lxc.console` is also a
>> good thing to try, although it is not set in my system too. Probably it can
>> be the easiest fix.
>>
>> I don't run with `lxc.aa_profile = unconfined` and `lxc.cap.drop=`, so in
>> your system container can do more things than it can do here.
>>
>> --
>>
>> With Best Regards,
>> Marat Khalili
>>
>>
>> ___
>> lxc-users mailing list
>> lxc-users@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

THAT WORKED
But the new key is
lxc.tty.dir = lxc


On Thu, Nov 16, 2017 at 9:32 AM, Marat Khalili  wrote:

> On 16/11/17 14:58, Saint Michael wrote:
>
> lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
> lxc.mount.entry = sysfs sys sysfs defaults  0 0
> lxc.mount.entry = /cdr cdr none bind 0 0
> lxc.mount.auto = cgroup:mixed
> lxc.tty = 10
> lxc.pts = 1024
> lxc.cgroup.devices.deny = a
> lxc.cgroup.devices.allow = c 1:3 rwm
> lxc.cgroup.devices.allow = c 1:5 rwm
> lxc.cgroup.devices.allow = c 5:1 rwm
> lxc.cgroup.devices.allow = c 5:0 rwm
> lxc.cgroup.devices.allow = c 4:0 rwm
> lxc.cgroup.devices.allow = c 4:1 rwm
> lxc.cgroup.devices.allow = c 1:9 rwm
> lxc.cgroup.devices.allow = c 1:8 rwm
> lxc.cgroup.devices.allow = c 136:* rwm
> lxc.cgroup.devices.allow = c 5:2 rwm
> lxc.cgroup.devices.allow = c 254:0 rwm
> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
> lxc.cgroup.devices.allow = b 7:* rwm# loop*
> lxc.cgroup.devices.allow = c 10:229 rwm #fuse
> lxc.autodev = 0
> lxc.aa_profile = unconfined
> lxc.cap.drop=
> lxc.network.type = phys
> lxc.network.flags = up
> lxc.network.link = eth6
> lxc.network.name = eth0
> lxc.network.ipv4 = 0.0.0.0/27
> lxc.network.type = macvlan
> lxc.network.flags = up
> lxc.network.link = eth3
> lxc.network.name = eth1
> lxc.network.macvlan.mode = bridge
> lxc.network.ipv4 = 0.0.0.0/24
>
> lxc.start.auto = 1
> lxc.start.delay = 5
> lxc.start.order = 0
> lxc.rootfs = /data/iplinkcdr/rootfs
> lxc.rootfs.backend = dir
> lxc.utsname = iplinkcdr
>
>
> It does not look as config created by lxc-create. Does same thing happen
> if you use `lxc-create -t download`?
>
> Looking at your config, I most notably don't see `lxc.devttydir = lxc`.
> Although according to man it should not directly cause effect you
> described, but I'd still try to add it and see. `lxc.console` is also a
> good thing to try, although it is not set in my system too. Probably it can
> be the easiest fix.
>
> I don't run with `lxc.aa_profile = unconfined` and `lxc.cap.drop=`, so in
> your system container can do more things than it can do here.
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Marat Khalili]

On 16/11/17 14:58, Saint Michael wrote:

lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry = sysfs sys sysfs defaults  0 0
lxc.mount.entry = /cdr cdr none bind 0 0
lxc.mount.auto = cgroup:mixed
lxc.tty = 10
lxc.pts = 1024
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
lxc.cgroup.devices.allow = c 254:0 rwm
lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
lxc.cgroup.devices.allow = b 7:* rwm    # loop*
lxc.cgroup.devices.allow = c 10:229 rwm #fuse
lxc.autodev = 0
lxc.aa_profile = unconfined
lxc.cap.drop=
lxc.network.type = phys
lxc.network.flags = up
lxc.network.link = eth6
lxc.network.name  = eth0
lxc.network.ipv4 = 0.0.0.0/27 
lxc.network.type = macvlan
lxc.network.flags = up
lxc.network.link = eth3
lxc.network.name  = eth1
lxc.network.macvlan.mode = bridge
lxc.network.ipv4 = 0.0.0.0/24 

lxc.start.auto = 1
lxc.start.delay = 5
lxc.start.order = 0
lxc.rootfs = /data/iplinkcdr/rootfs
lxc.rootfs.backend = dir
lxc.utsname = iplinkcdr


It does not look as config created by lxc-create. Does same thing happen 
if you use `lxc-create -t download`?


Looking at your config, I most notably don't see `lxc.devttydir = lxc`. 
Although according to man it should not directly cause effect you 
described, but I'd still try to add it and see. `lxc.console` is also a 
good thing to try, although it is not set in my system too. Probably it 
can be the easiest fix.


I don't run with `lxc.aa_profile = unconfined` and `lxc.cap.drop=`, so 
in your system container can do more things than it can do here.


--

With Best Regards,
Marat Khalili

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Andrey Repin]

Greetings, Saint Michael!

> I use full privileged containers, since this is just a mechanism to move
> around higly complex installations.
> In my business there is one host and one container per box, which uses up
> all resources available.
> What you are saying, basically, is the root-privileged containers is not
> support by LXC, since a container does hijack the host's TTY.

No, it should not. Although I didn't use it on 16.04, but my older LTS'es use
a bunch of privileged containers to encapsulate separate services, and none
exhibit the issue described.
$  lxc-start --version
2.0.8

> Any confirmation of this? I cannot believe this is impossible to solve.

It is most likely possible to solve. Please see another branch of this thread.

OTOH, using unprivileged containers is strongly suggested for general security
considerations.


-- 
With best regards,
Andrey Repin
Thursday, November 16, 2017 16:11:02

Sorry for my terrible english...

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

This is the view of the container's /dev

console  fd  full  fuse  initctl  null  ptmx  pts  random  shm  stderr
stdin  stdout  tty  tty1  tty10  tty2  tty3  tty4  tty5  tty6  tty7  tty8
tty9  urandom  zero

rom the host

Please not that I erased tty0, based on advise I found on the Internet. I
also did this inside the container

systemctl stop console-getty
systemctl disable console-getty
systemctl mask console-getty

remove /dev/tty0
systemctl stop getty@tty1.service; systemctl mask getty@tty1.service

but it keeps happening.
Philip

On Thu, Nov 16, 2017 at 6:58 AM, Saint Michael  wrote:

> lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
> lxc.mount.entry = sysfs sys sysfs defaults  0 0
> lxc.mount.entry = /cdr cdr none bind 0 0
> lxc.mount.auto = cgroup:mixed
> lxc.tty = 10
> lxc.pts = 1024
> lxc.cgroup.devices.deny = a
> lxc.cgroup.devices.allow = c 1:3 rwm
> lxc.cgroup.devices.allow = c 1:5 rwm
> lxc.cgroup.devices.allow = c 5:1 rwm
> lxc.cgroup.devices.allow = c 5:0 rwm
> lxc.cgroup.devices.allow = c 4:0 rwm
> lxc.cgroup.devices.allow = c 4:1 rwm
> lxc.cgroup.devices.allow = c 1:9 rwm
> lxc.cgroup.devices.allow = c 1:8 rwm
> lxc.cgroup.devices.allow = c 136:* rwm
> lxc.cgroup.devices.allow = c 5:2 rwm
> lxc.cgroup.devices.allow = c 254:0 rwm
> lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
> lxc.cgroup.devices.allow = b 7:* rwm# loop*
> lxc.cgroup.devices.allow = c 10:229 rwm #fuse
> lxc.autodev = 0
> lxc.aa_profile = unconfined
> lxc.cap.drop=
> lxc.network.type = phys
> lxc.network.flags = up
> lxc.network.link = eth6
> lxc.network.name = eth0
> lxc.network.ipv4 = 0.0.0.0/27
> lxc.network.type = macvlan
> lxc.network.flags = up
> lxc.network.link = eth3
> lxc.network.name = eth1
> lxc.network.macvlan.mode = bridge
> lxc.network.ipv4 = 0.0.0.0/24
>
> lxc.start.auto = 1
> lxc.start.delay = 5
> lxc.start.order = 0
> lxc.rootfs = /data/iplinkcdr/rootfs
> lxc.rootfs.backend = dir
> lxc.utsname = iplinkcdr
>
> On Thu, Nov 16, 2017 at 3:19 AM, Marat Khalili  wrote:
>
>> I'm using LXC on 16.04 and observe nothing of the kind you describe. How
>> are you creating containers? Please post container config file.
>>
>> --
>>
>> With Best Regards,
>> Marat Khalili
>>
>>
>> ___
>> lxc-users mailing list
>> lxc-users@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry = sysfs sys sysfs defaults  0 0
lxc.mount.entry = /cdr cdr none bind 0 0
lxc.mount.auto = cgroup:mixed
lxc.tty = 10
lxc.pts = 1024
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
lxc.cgroup.devices.allow = c 254:0 rwm
lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
lxc.cgroup.devices.allow = b 7:* rwm# loop*
lxc.cgroup.devices.allow = c 10:229 rwm #fuse
lxc.autodev = 0
lxc.aa_profile = unconfined
lxc.cap.drop=
lxc.network.type = phys
lxc.network.flags = up
lxc.network.link = eth6
lxc.network.name = eth0
lxc.network.ipv4 = 0.0.0.0/27
lxc.network.type = macvlan
lxc.network.flags = up
lxc.network.link = eth3
lxc.network.name = eth1
lxc.network.macvlan.mode = bridge
lxc.network.ipv4 = 0.0.0.0/24

lxc.start.auto = 1
lxc.start.delay = 5
lxc.start.order = 0
lxc.rootfs = /data/iplinkcdr/rootfs
lxc.rootfs.backend = dir
lxc.utsname = iplinkcdr

On Thu, Nov 16, 2017 at 3:19 AM, Marat Khalili  wrote:

> I'm using LXC on 16.04 and observe nothing of the kind you describe. How
> are you creating containers? Please post container config file.
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Marat Khalili]

I'm using LXC on 16.04 and observe nothing of the kind you describe. How 
are you creating containers? Please post container config file.


--

With Best Regards,
Marat Khalili

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

I use full privileged containers, since this is just a mechanism to move
around higly complex installations.
In my business there is one host and one container per box, which uses up
all resources available.
What you are saying, basically, is the root-privileged containers is not
support by LXC, since a container does hijack the host's TTY.
Any confirmation of this?
I cannot believe this is impossible to solve.


On Wed, Nov 15, 2017 at 10:19 PM, Fajar A. Nugraha  wrote:

> On Thu, Nov 16, 2017 at 10:04 AM, Saint Michael  wrote:
>
>> I did apply all suggested solutions that you found googling. None works.
>> I do not use LXD, just plain LXC.
>> lxc-start --version
>> 2.0.9
>> lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 16.04.3 LTS
>> Release:16.04
>> Codename:   xenial
>>
>>
>>
> Short version: use root-owned unprivileged containers.
> If you don't know how to do that (or think it's too troublesome to
> configure with lxc), then just use LXD (which use root-owned unprivileged
> containers by default).
>
> --
> Fajar
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Fajar A. Nugraha]

On Thu, Nov 16, 2017 at 10:04 AM, Saint Michael  wrote:

> I did apply all suggested solutions that you found googling. None works.
> I do not use LXD, just plain LXC.
> lxc-start --version
> 2.0.9
> lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 16.04.3 LTS
> Release:16.04
> Codename:   xenial
>
>
>
Short version: use root-owned unprivileged containers.
If you don't know how to do that (or think it's too troublesome to
configure with lxc), then just use LXD (which use root-owned unprivileged
containers by default).

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Saint Michael]

I did apply all suggested solutions that you found googling. None works.
I do not use LXD, just plain LXC.
lxc-start --version
2.0.9
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.3 LTS
Release:16.04
Codename:   xenial


On Wed, Nov 15, 2017 at 9:42 PM, Andrey Repin  wrote:

> Greetings, Saint Michael!
>
> > My host is Ubuntu LTS
>
> Which "LTS"?…
>
> > and my container is Centos 7.
>
> And what you are using for containers?
> LXC? LXD? Which version?
>
> > Every time the server boots, the container takes over the tty0 of the
> > server, Ubuntu, and freezes the interface.
> > The only way to log to the server itsef is to press ALT+F2 and use the
> second tty.
> > I tried to remove tty0 on the guest, and also this (on the guest)
> > systemctl stop getty@tty1.service; systemctl mask getty@tty1.service
> > but the issue continues. Any idea how can I block any container from
> > hijacking te host's tty?
>
> Your report lacking a lot of critical information. And it doesn't look like
> you did a google on your problem either. I was able to easily find a
> number of
> references to similar issues, and they all contain suggested solutions,
> unfortunately, without a call back from the original poster(s) about
> success/failure of applying them.
>
>
> --
> With best regards,
> Andrey Repin
> Thursday, November 16, 2017 05:37:58
>
> Sorry for my terrible english...
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] TTY issue

[Andrey Repin]

Greetings, Saint Michael!

> My host is Ubuntu LTS

Which "LTS"?…

> and my container is Centos 7.

And what you are using for containers?
LXC? LXD? Which version?

> Every time the server boots, the container takes over the tty0 of the
> server, Ubuntu, and freezes the interface.
> The only way to log to the server itsef is to press ALT+F2 and use the second 
> tty.
> I tried to remove tty0 on the guest, and also this (on the guest)
> systemctl stop getty@tty1.service; systemctl mask getty@tty1.service
> but the issue continues. Any idea how can I block any container from
> hijacking te host's tty?

Your report lacking a lot of critical information. And it doesn't look like
you did a google on your problem either. I was able to easily find a number of
references to similar issues, and they all contain suggested solutions,
unfortunately, without a call back from the original poster(s) about
success/failure of applying them.


-- 
With best regards,
Andrey Repin
Thursday, November 16, 2017 05:37:58

Sorry for my terrible english...
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] TTY issue

[Saint Michael]

My host is Ubuntu LTS and my container is Centos 7. Every time the server
boots, the container takes over the tty0 of the server, Ubuntu, and freezes
the interface. The only way to log to the server itsef is to press ALT+F2
and use the second tty. I tried to remobve tty0 on the gest, and also this
(on the guest)
systemctl stop getty@tty1.service; systemctl mask getty@tty1.service
but the issue continues. Any idea how can I block any container from
hijacking te host's tty?
Philip
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users