Re: Черный экран с курсором

[Vasiliy P. Melnik]

попробовать добавить nomodeset

BOOT_IMAGE=/vmlinuz-2.6.32-27-pve root=/dev/mapper/pve-root ro quiet

29 июня 2016 г., 1:17 пользователь Anatoly Molchanov 
написал:

> в /proc/cmdline у меня только:
> BOOT_IMAGE=/vmlinuz-2.6.32-27-pve root=/dev/mapper/pve-root ro quiet
>
> Это Proxmox 3й версии на базе Debian 7.
>
> 29 июня 2016 г., 1:15 пользователь Max Dmitrichenko 
> написал:
>
>> Ну тогда надо попробовать покапать в стору фреймбуфера. Как он там
>> настраивается через параметры ядра вроде. Давайте на /proc/cmdline
>> посмотрим.
>>
>> 29 июня 2016 г., 1:09 пользователь Anatoly Molchanov
>>  написал:
>> > спасибо. попробовал, но картинка та же
>> >
>> > 29 июня 2016 г., 1:08 пользователь Max Dmitrichenko > >
>> > написал:
>> >
>> >> 1:2345:respawn:/sbin/getty 38400 tty1
>> >>
>> >> respawn означает, что перезапустить процесс, если он завершился. Смело
>> >> убивайте все getty и напишите результат. Если дело не в этом, то надо
>> >> копать в сторону фреймбуфера консоли. Других вариантов на ум не
>> >> приходит
>> >>
>> >> 29 июня 2016 г., 1:05 пользователь Anatoly Molchanov
>> >>  написал:
>> >> > /etc/inittab:
>> >> > id:2:initdefault:
>> >> > si::sysinit:/etc/init.d/rcS
>> >> > ~~:S:wait:/sbin/sulogin
>> >> > l0:0:wait:/etc/init.d/rc 0
>> >> > l1:1:wait:/etc/init.d/rc 1
>> >> > l2:2:wait:/etc/init.d/rc 2
>> >> > l3:3:wait:/etc/init.d/rc 3
>> >> > l4:4:wait:/etc/init.d/rc 4
>> >> > l5:5:wait:/etc/init.d/rc 5
>> >> > l6:6:wait:/etc/init.d/rc 6
>> >> > z6:6:respawn:/sbin/sulogin
>> >> > ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
>> >> > pf::powerwait:/etc/init.d/powerfail start
>> >> > pn::powerfailnow:/etc/init.d/powerfail now
>> >> > po::powerokwait:/etc/init.d/powerfail stop
>> >> > 1:2345:respawn:/sbin/getty 38400 tty1
>> >> > 2:23:respawn:/sbin/getty 38400 tty2
>> >> > 3:23:respawn:/sbin/getty 38400 tty3
>> >> > 4:23:respawn:/sbin/getty 38400 tty4
>> >> > 5:23:respawn:/sbin/getty 38400 tty5
>> >> > 6:23:respawn:/sbin/getty 38400 tty6
>> >> >
>> >> >
>> >> > 29 июня 2016 г., 1:04 пользователь Max Dmitrichenko <
>> dmitr...@gmail.com>
>> >> > написал:
>> >> >
>> >> >> Кстати, достаточно сказать
>> >> >> # killall -9 getty
>> >> >>
>> >> >> Олдскульный init их сам должен пореспаунить после этого.
>> >> >>
>> >> >> 29 июня 2016 г., 1:02 пользователь Max Dmitrichenko
>> >> >>  написал:
>> >> >> > 29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
>> >> >> >  написал:
>> >> >> >> в Debian 7 ?
>> >> >> >
>> >> >> > Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
>> >> >> > содержимое /etc/inittab тогда. Будем по старинке раскуривать
>> SysV. На
>> >> >> > сколько я помню, getty запускается именно по велению
>> /etc/inittab, а
>> >> >> > отдельного сервиса действительно нет и не должно быть.
>> >> >> >
>> >> >> > --
>> >> >> > With best regards
>> >> >> >   Max Dmitrichenko
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> With best regards
>> >> >>   Max Dmitrichenko
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> With best regards
>> >>   Max Dmitrichenko
>> >
>> >
>>
>>
>>
>> --
>> With best regards
>>   Max Dmitrichenko
>>
>
>

Re: Черный экран с курсором

[Anatoly Molchanov]

console-tools последний стоит. никаких приколистов не было ))

29 июня 2016 г., 1:24 пользователь Max Dmitrichenko 
написал:

> 29 июня 2016 г., 1:22 пользователь Max Dmitrichenko
>  написал:
> > Черт его знает. Такое ощущение, что какой-то приколист поменял цвет
> > шрифта на черный )
>
> В семерке был такой пакет console-tools, он вроде ставил сервис,
> который на старте дергался и устанавливал шрифты. Может подергать этот
> сервис, чтобы он переустановил их?
>
> --
> With best regards
>   Max Dmitrichenko
>

Re: Черный экран с курсором

[Anatoly Molchanov]

Мужчины, спасибо за помощь. Еще вижу много tty'ев в /dev (30+ штук)

29 июня 2016 г., 1:17 пользователь Max Dmitrichenko 
написал:

> 29 июня 2016 г., 1:12 пользователь Artem Chuprina 
> написал:
> > (systemd, кстати, тоже)
>
> Я совсем не специалист в systemd, но что-то смутно припоминаю, что там
> была и какая-то другая логика, которая запускала getty on demand, типа
> что пока на эту консоль никто не переключился, никакого getty и не
> надо. Снилось ли мне это?
>
> --
> With best regards
>   Max Dmitrichenko
>

Re: Черный экран с курсором

[Max Dmitrichenko]

29 июня 2016 г., 1:22 пользователь Max Dmitrichenko
 написал:
> Черт его знает. Такое ощущение, что какой-то приколист поменял цвет
> шрифта на черный )

В семерке был такой пакет console-tools, он вроде ставил сервис,
который на старте дергался и устанавливал шрифты. Может подергать этот
сервис, чтобы он переустановил их?

-- 
With best regards
  Max Dmitrichenko

Re: Черный экран с курсором

[Max Dmitrichenko]

29 июня 2016 г., 1:16 пользователь Anatoly Molchanov
 написал:
> Сервер IBM x-серии, были глюки на VGA-выходе(другого сервера) через IPMI, но
> на текущем косяк и через IPMI и напрямую с материнки. Мне кажется, что это
> не христоматийный случай, так как курсор бегает и реагирует на ввод
> адекватно.

Ну если cmdline на этот счёт молчит, то скорее всего у вас vesafb,
если вы grub на VGA не переконфигурили
Как он работает, если честно - хз.

Черт его знает. Такое ощущение, что какой-то приколист поменял цвет
шрифта на черный )

-- 
With best regards
  Max Dmitrichenko

Re: Черный экран с курсором

[Anatoly Molchanov]

в /proc/cmdline у меня только:
BOOT_IMAGE=/vmlinuz-2.6.32-27-pve root=/dev/mapper/pve-root ro quiet

Это Proxmox 3й версии на базе Debian 7.

29 июня 2016 г., 1:15 пользователь Max Dmitrichenko 
написал:

> Ну тогда надо попробовать покапать в стору фреймбуфера. Как он там
> настраивается через параметры ядра вроде. Давайте на /proc/cmdline
> посмотрим.
>
> 29 июня 2016 г., 1:09 пользователь Anatoly Molchanov
>  написал:
> > спасибо. попробовал, но картинка та же
> >
> > 29 июня 2016 г., 1:08 пользователь Max Dmitrichenko 
> > написал:
> >
> >> 1:2345:respawn:/sbin/getty 38400 tty1
> >>
> >> respawn означает, что перезапустить процесс, если он завершился. Смело
> >> убивайте все getty и напишите результат. Если дело не в этом, то надо
> >> копать в сторону фреймбуфера консоли. Других вариантов на ум не
> >> приходит
> >>
> >> 29 июня 2016 г., 1:05 пользователь Anatoly Molchanov
> >>  написал:
> >> > /etc/inittab:
> >> > id:2:initdefault:
> >> > si::sysinit:/etc/init.d/rcS
> >> > ~~:S:wait:/sbin/sulogin
> >> > l0:0:wait:/etc/init.d/rc 0
> >> > l1:1:wait:/etc/init.d/rc 1
> >> > l2:2:wait:/etc/init.d/rc 2
> >> > l3:3:wait:/etc/init.d/rc 3
> >> > l4:4:wait:/etc/init.d/rc 4
> >> > l5:5:wait:/etc/init.d/rc 5
> >> > l6:6:wait:/etc/init.d/rc 6
> >> > z6:6:respawn:/sbin/sulogin
> >> > ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
> >> > pf::powerwait:/etc/init.d/powerfail start
> >> > pn::powerfailnow:/etc/init.d/powerfail now
> >> > po::powerokwait:/etc/init.d/powerfail stop
> >> > 1:2345:respawn:/sbin/getty 38400 tty1
> >> > 2:23:respawn:/sbin/getty 38400 tty2
> >> > 3:23:respawn:/sbin/getty 38400 tty3
> >> > 4:23:respawn:/sbin/getty 38400 tty4
> >> > 5:23:respawn:/sbin/getty 38400 tty5
> >> > 6:23:respawn:/sbin/getty 38400 tty6
> >> >
> >> >
> >> > 29 июня 2016 г., 1:04 пользователь Max Dmitrichenko <
> dmitr...@gmail.com>
> >> > написал:
> >> >
> >> >> Кстати, достаточно сказать
> >> >> # killall -9 getty
> >> >>
> >> >> Олдскульный init их сам должен пореспаунить после этого.
> >> >>
> >> >> 29 июня 2016 г., 1:02 пользователь Max Dmitrichenko
> >> >>  написал:
> >> >> > 29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
> >> >> >  написал:
> >> >> >> в Debian 7 ?
> >> >> >
> >> >> > Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
> >> >> > содержимое /etc/inittab тогда. Будем по старинке раскуривать SysV.
> На
> >> >> > сколько я помню, getty запускается именно по велению /etc/inittab,
> а
> >> >> > отдельного сервиса действительно нет и не должно быть.
> >> >> >
> >> >> > --
> >> >> > With best regards
> >> >> >   Max Dmitrichenko
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> With best regards
> >> >>   Max Dmitrichenko
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> With best regards
> >>   Max Dmitrichenko
> >
> >
>
>
>
> --
> With best regards
>   Max Dmitrichenko
>

Re: Черный экран с курсором

[Max Dmitrichenko]

29 июня 2016 г., 1:12 пользователь Artem Chuprina  написал:
> (systemd, кстати, тоже)

Я совсем не специалист в systemd, но что-то смутно припоминаю, что там
была и какая-то другая логика, которая запускала getty on demand, типа
что пока на эту консоль никто не переключился, никакого getty и не
надо. Снилось ли мне это?

-- 
With best regards
  Max Dmitrichenko

Re: Черный экран с курсором

[Anatoly Molchanov]

Сервер IBM x-серии, были глюки на VGA-выходе(другого сервера) через IPMI,
но на текущем косяк и через IPMI и напрямую с материнки. Мне кажется, что
это не христоматийный случай, так как курсор бегает и реагирует на ввод
адекватно.

29 июня 2016 г., 1:12 пользователь Artem Chuprina 
написал:

> Max Dmitrichenko -> Anatoly Molchanov  @ Wed, 29 Jun 2016 01:04:20 +0300:
>
>  > Кстати, достаточно сказать
>  > # killall -9 getty
>
>  > Олдскульный init их сам должен пореспаунить после этого.
>
> (systemd, кстати, тоже) Однако, описание поведения как бы намекает, что
> это вряд ли спасет ситуацию.  Если Анатолий не только входил вслепую, но
> и выходил, то там, где он вышел, getty уже перезапустился.  И раз он не
> сумел проинитить терминал так, чтобы буквы стало видно, то еще раз
> прибить, скорее всего, тоже не поможет.
>
> Я подозреваю глюки в графике.  У нас же нынче консоль по умолчанию либо
> продвинутая *VGA, либо framebuffer, и всё это работает на продвинутых
> режимах карточки.  Либо на неконвенционном текстовом режиме (где у
> каждой карты свои глюки), либо вообще поверх графического, тоже нифига
> не bare VGA.
>
>

Re: Черный экран с курсором

[Max Dmitrichenko]

Ну тогда надо попробовать покапать в стору фреймбуфера. Как он там
настраивается через параметры ядра вроде. Давайте на /proc/cmdline
посмотрим.

29 июня 2016 г., 1:09 пользователь Anatoly Molchanov
 написал:
> спасибо. попробовал, но картинка та же
>
> 29 июня 2016 г., 1:08 пользователь Max Dmitrichenko 
> написал:
>
>> 1:2345:respawn:/sbin/getty 38400 tty1
>>
>> respawn означает, что перезапустить процесс, если он завершился. Смело
>> убивайте все getty и напишите результат. Если дело не в этом, то надо
>> копать в сторону фреймбуфера консоли. Других вариантов на ум не
>> приходит
>>
>> 29 июня 2016 г., 1:05 пользователь Anatoly Molchanov
>>  написал:
>> > /etc/inittab:
>> > id:2:initdefault:
>> > si::sysinit:/etc/init.d/rcS
>> > ~~:S:wait:/sbin/sulogin
>> > l0:0:wait:/etc/init.d/rc 0
>> > l1:1:wait:/etc/init.d/rc 1
>> > l2:2:wait:/etc/init.d/rc 2
>> > l3:3:wait:/etc/init.d/rc 3
>> > l4:4:wait:/etc/init.d/rc 4
>> > l5:5:wait:/etc/init.d/rc 5
>> > l6:6:wait:/etc/init.d/rc 6
>> > z6:6:respawn:/sbin/sulogin
>> > ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
>> > pf::powerwait:/etc/init.d/powerfail start
>> > pn::powerfailnow:/etc/init.d/powerfail now
>> > po::powerokwait:/etc/init.d/powerfail stop
>> > 1:2345:respawn:/sbin/getty 38400 tty1
>> > 2:23:respawn:/sbin/getty 38400 tty2
>> > 3:23:respawn:/sbin/getty 38400 tty3
>> > 4:23:respawn:/sbin/getty 38400 tty4
>> > 5:23:respawn:/sbin/getty 38400 tty5
>> > 6:23:respawn:/sbin/getty 38400 tty6
>> >
>> >
>> > 29 июня 2016 г., 1:04 пользователь Max Dmitrichenko 
>> > написал:
>> >
>> >> Кстати, достаточно сказать
>> >> # killall -9 getty
>> >>
>> >> Олдскульный init их сам должен пореспаунить после этого.
>> >>
>> >> 29 июня 2016 г., 1:02 пользователь Max Dmitrichenko
>> >>  написал:
>> >> > 29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
>> >> >  написал:
>> >> >> в Debian 7 ?
>> >> >
>> >> > Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
>> >> > содержимое /etc/inittab тогда. Будем по старинке раскуривать SysV. На
>> >> > сколько я помню, getty запускается именно по велению /etc/inittab, а
>> >> > отдельного сервиса действительно нет и не должно быть.
>> >> >
>> >> > --
>> >> > With best regards
>> >> >   Max Dmitrichenko
>> >>
>> >>
>> >>
>> >> --
>> >> With best regards
>> >>   Max Dmitrichenko
>> >
>> >
>>
>>
>>
>> --
>> With best regards
>>   Max Dmitrichenko
>
>



-- 
With best regards
  Max Dmitrichenko

Re: Черный экран с курсором

[Artem Chuprina]

Max Dmitrichenko -> Anatoly Molchanov  @ Wed, 29 Jun 2016 01:04:20 +0300:

 > Кстати, достаточно сказать
 > # killall -9 getty

 > Олдскульный init их сам должен пореспаунить после этого.

(systemd, кстати, тоже) Однако, описание поведения как бы намекает, что
это вряд ли спасет ситуацию.  Если Анатолий не только входил вслепую, но
и выходил, то там, где он вышел, getty уже перезапустился.  И раз он не
сумел проинитить терминал так, чтобы буквы стало видно, то еще раз
прибить, скорее всего, тоже не поможет.

Я подозреваю глюки в графике.  У нас же нынче консоль по умолчанию либо
продвинутая *VGA, либо framebuffer, и всё это работает на продвинутых
режимах карточки.  Либо на неконвенционном текстовом режиме (где у
каждой карты свои глюки), либо вообще поверх графического, тоже нифига
не bare VGA.

Re: Черный экран с курсором

[Anatoly Molchanov]

спасибо. попробовал, но картинка та же

29 июня 2016 г., 1:08 пользователь Max Dmitrichenko 
написал:

> 1:2345:respawn:/sbin/getty 38400 tty1
>
> respawn означает, что перезапустить процесс, если он завершился. Смело
> убивайте все getty и напишите результат. Если дело не в этом, то надо
> копать в сторону фреймбуфера консоли. Других вариантов на ум не
> приходит
>
> 29 июня 2016 г., 1:05 пользователь Anatoly Molchanov
>  написал:
> > /etc/inittab:
> > id:2:initdefault:
> > si::sysinit:/etc/init.d/rcS
> > ~~:S:wait:/sbin/sulogin
> > l0:0:wait:/etc/init.d/rc 0
> > l1:1:wait:/etc/init.d/rc 1
> > l2:2:wait:/etc/init.d/rc 2
> > l3:3:wait:/etc/init.d/rc 3
> > l4:4:wait:/etc/init.d/rc 4
> > l5:5:wait:/etc/init.d/rc 5
> > l6:6:wait:/etc/init.d/rc 6
> > z6:6:respawn:/sbin/sulogin
> > ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
> > pf::powerwait:/etc/init.d/powerfail start
> > pn::powerfailnow:/etc/init.d/powerfail now
> > po::powerokwait:/etc/init.d/powerfail stop
> > 1:2345:respawn:/sbin/getty 38400 tty1
> > 2:23:respawn:/sbin/getty 38400 tty2
> > 3:23:respawn:/sbin/getty 38400 tty3
> > 4:23:respawn:/sbin/getty 38400 tty4
> > 5:23:respawn:/sbin/getty 38400 tty5
> > 6:23:respawn:/sbin/getty 38400 tty6
> >
> >
> > 29 июня 2016 г., 1:04 пользователь Max Dmitrichenko 
> > написал:
> >
> >> Кстати, достаточно сказать
> >> # killall -9 getty
> >>
> >> Олдскульный init их сам должен пореспаунить после этого.
> >>
> >> 29 июня 2016 г., 1:02 пользователь Max Dmitrichenko
> >>  написал:
> >> > 29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
> >> >  написал:
> >> >> в Debian 7 ?
> >> >
> >> > Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
> >> > содержимое /etc/inittab тогда. Будем по старинке раскуривать SysV. На
> >> > сколько я помню, getty запускается именно по велению /etc/inittab, а
> >> > отдельного сервиса действительно нет и не должно быть.
> >> >
> >> > --
> >> > With best regards
> >> >   Max Dmitrichenko
> >>
> >>
> >>
> >> --
> >> With best regards
> >>   Max Dmitrichenko
> >
> >
>
>
>
> --
> With best regards
>   Max Dmitrichenko
>

Re: Черный экран с курсором

[Max Dmitrichenko]

1:2345:respawn:/sbin/getty 38400 tty1

respawn означает, что перезапустить процесс, если он завершился. Смело
убивайте все getty и напишите результат. Если дело не в этом, то надо
копать в сторону фреймбуфера консоли. Других вариантов на ум не
приходит

29 июня 2016 г., 1:05 пользователь Anatoly Molchanov
 написал:
> /etc/inittab:
> id:2:initdefault:
> si::sysinit:/etc/init.d/rcS
> ~~:S:wait:/sbin/sulogin
> l0:0:wait:/etc/init.d/rc 0
> l1:1:wait:/etc/init.d/rc 1
> l2:2:wait:/etc/init.d/rc 2
> l3:3:wait:/etc/init.d/rc 3
> l4:4:wait:/etc/init.d/rc 4
> l5:5:wait:/etc/init.d/rc 5
> l6:6:wait:/etc/init.d/rc 6
> z6:6:respawn:/sbin/sulogin
> ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
> pf::powerwait:/etc/init.d/powerfail start
> pn::powerfailnow:/etc/init.d/powerfail now
> po::powerokwait:/etc/init.d/powerfail stop
> 1:2345:respawn:/sbin/getty 38400 tty1
> 2:23:respawn:/sbin/getty 38400 tty2
> 3:23:respawn:/sbin/getty 38400 tty3
> 4:23:respawn:/sbin/getty 38400 tty4
> 5:23:respawn:/sbin/getty 38400 tty5
> 6:23:respawn:/sbin/getty 38400 tty6
>
>
> 29 июня 2016 г., 1:04 пользователь Max Dmitrichenko 
> написал:
>
>> Кстати, достаточно сказать
>> # killall -9 getty
>>
>> Олдскульный init их сам должен пореспаунить после этого.
>>
>> 29 июня 2016 г., 1:02 пользователь Max Dmitrichenko
>>  написал:
>> > 29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
>> >  написал:
>> >> в Debian 7 ?
>> >
>> > Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
>> > содержимое /etc/inittab тогда. Будем по старинке раскуривать SysV. На
>> > сколько я помню, getty запускается именно по велению /etc/inittab, а
>> > отдельного сервиса действительно нет и не должно быть.
>> >
>> > --
>> > With best regards
>> >   Max Dmitrichenko
>>
>>
>>
>> --
>> With best regards
>>   Max Dmitrichenko
>
>



-- 
With best regards
  Max Dmitrichenko

Re: Черный экран с курсором

[Max Dmitrichenko]

29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
 написал:
> в Debian 7 ?

Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
содержимое /etc/inittab тогда. Будем по старинке раскуривать SysV. На
сколько я помню, getty запускается именно по велению /etc/inittab, а
отдельного сервиса действительно нет и не должно быть.

-- 
With best regards
  Max Dmitrichenko

Re: Черный экран с курсором

[Anatoly Molchanov]

/etc/inittab:
id:2:initdefault:
si::sysinit:/etc/init.d/rcS
~~:S:wait:/sbin/sulogin
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
z6:6:respawn:/sbin/sulogin
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6


29 июня 2016 г., 1:04 пользователь Max Dmitrichenko 
написал:

> Кстати, достаточно сказать
> # killall -9 getty
>
> Олдскульный init их сам должен пореспаунить после этого.
>
> 29 июня 2016 г., 1:02 пользователь Max Dmitrichenko
>  написал:
> > 29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
> >  написал:
> >> в Debian 7 ?
> >
> > Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
> > содержимое /etc/inittab тогда. Будем по старинке раскуривать SysV. На
> > сколько я помню, getty запускается именно по велению /etc/inittab, а
> > отдельного сервиса действительно нет и не должно быть.
> >
> > --
> > With best regards
> >   Max Dmitrichenko
>
>
>
> --
> With best regards
>   Max Dmitrichenko
>

Re: ограничить трафик в час?

[Artem Chuprina]

Кузьмин Андрей -> Artem Chuprina  @ Tue, 28 Jun 2016 23:29:15 +0300:

 > Помнится мне есть такая утила шейпер называется, может с помощью нее все 
 > решить можно? 

Это буквосочетание tc из моего первого письма.  Та же проблема - он
заточен под аккуратное обеспечение пропускной способности,
т.е. равномерности.  И алгоритм там соответствующий.  А мне надо
ограничить трафик за довольно большой промежуток времени, совершенно не
обязательно равномерный (более того, как раз наоборот, в норме сильно
НЕравномерный).

В общем, да, задача скорее на квоты, чем на шейпинг, и hashlimit мне тут
привлекателен именно как самовосстанавливающаяся квота, а не как шейпер.

 > 28.06.2016, 11:44, "Artem Chuprina" :
 >> Eugene Berdnikov -> debian-russian@lists.debian.org @ Tue, 28 Jun 2016 
 >> 10:59:49 +0300:
 >>
 >>  >> Я хочу предоставлять некоторым визитерам своей квартиры гостевой доступ
 >>  >> в интернет, с ограничением вида "10 мегабайт на хост за два часа".
 >>  > ...
 >>  >> Посмотрел на hashlimit у iptables - оно умеет только в секунду.
 >>
 >>  > Судя по ману, hashlimit умеет и часы, и даже дни. Однако для этой
 >>  > задачи он плох тем, что в burst ему можно указать лишь число пакетов,
 >>  > а не объём трафика.
 >>
 >> Я почитал более тщательно. Время он умеет только при количестве
 >> пакетов. При байтах - только секунду.
 >>
 >> С другой стороны, в burst можно указывать байты. В соответствующем
 >> абзаце это сказано не шибко внятно, но там пример на это есть.
 >>
 >> Я вот думаю, может, для простоты сделать
 >>
 >> --hashlimit-above 1b/s --hashlimit-burst 10mb --hashlimit-htable-expire 
 >> 17280 ?
 >>
 >> (expire у него в миллисекундах...)
 >>
 >> quota тоже интересно, впрочем. Надо поэкспериментировать. С квотой
 >> только, боюсь, засада в том, что надо на каждый адрес отдельное правило.
 >> hashlimit хорош тем, что задается одно правило на всю подсеть, а считать
 >> можно попросить по каждому адресу отдельно.
 >>
 >> И задается статически. Я очень люблю свою статическую конфигурацию
 >> iptables, которая при старте системы поднимается iptables-restore из
 >> того, что было сохранено iptables-save.

Re: Черный экран с курсором

[Max Dmitrichenko]

Кстати, достаточно сказать
# killall -9 getty

Олдскульный init их сам должен пореспаунить после этого.

29 июня 2016 г., 1:02 пользователь Max Dmitrichenko
 написал:
> 29 июня 2016 г., 0:52 пользователь Anatoly Molchanov
>  написал:
>> в Debian 7 ?
>
> Мда, читал тред с конца ) Семерки под рукой уже нет. Кидайте сюды
> содержимое /etc/inittab тогда. Будем по старинке раскуривать SysV. На
> сколько я помню, getty запускается именно по велению /etc/inittab, а
> отдельного сервиса действительно нет и не должно быть.
>
> --
> With best regards
>   Max Dmitrichenko



-- 
With best regards
  Max Dmitrichenko

Re: Черный экран с курсором

[Anatoly Molchanov]

в Debian 7 ?

29 июня 2016 г., 0:50 пользователь Max Dmitrichenko 
написал:

> Systemd же!
> 29 июня 2016 г. 0:28 пользователь "Anatoly Molchanov" 
> написал:
>
> через прямое подключение к серверу(монитор, клавиатура) на всех
>> tty(ctrl+alt+f1, ctrl+alt+f2, ... ) симптомы одинаковы. через ssh все
>> абсолютно нормально. Сервиса getty нет, искал в /etc/init.d/getty, чтобы
>> /etc/init.d/getty restart
>>
>> 29 июня 2016 г., 0:15 пользователь dimas  написал:
>>
>>> такое на всех tty? tset не поможет? а getty перезапустить?
>>> по ssh, я так понимаю, шелл работает нормально?
>>>
>>>
>>> 2016-180 21:08 Anatoly Molchanov  wrote:
>>> > Добрый день, коллеги.
>>> >
>>> > Сервер на Debian 7 после 230 дней аптайма показывает черный экран с
>>> > мигающим курсором. На ввод реагирует смещением курсора, похоже что
>>> удалось
>>> > авторизоваться. Сервер, визуально, полностью работоспособен, никакого
>>> > криминала в логах нет, все сервисы работают штатно. Подскажите,
>>> пожалуйста,
>>> > как можно диагностировать?
>>>
>>>
>>

Re: Черный экран с курсором

[Max Dmitrichenko]

Systemd же!
29 июня 2016 г. 0:28 пользователь "Anatoly Molchanov" 
написал:

> через прямое подключение к серверу(монитор, клавиатура) на всех
> tty(ctrl+alt+f1, ctrl+alt+f2, ... ) симптомы одинаковы. через ssh все
> абсолютно нормально. Сервиса getty нет, искал в /etc/init.d/getty, чтобы
> /etc/init.d/getty restart
>
> 29 июня 2016 г., 0:15 пользователь dimas  написал:
>
>> такое на всех tty? tset не поможет? а getty перезапустить?
>> по ssh, я так понимаю, шелл работает нормально?
>>
>>
>> 2016-180 21:08 Anatoly Molchanov  wrote:
>> > Добрый день, коллеги.
>> >
>> > Сервер на Debian 7 после 230 дней аптайма показывает черный экран с
>> > мигающим курсором. На ввод реагирует смещением курсора, похоже что
>> удалось
>> > авторизоваться. Сервер, визуально, полностью работоспособен, никакого
>> > криминала в логах нет, все сервисы работают штатно. Подскажите,
>> пожалуйста,
>> > как можно диагностировать?
>>
>>
>

Re: Черный экран с курсором

[Anatoly Molchanov]

через прямое подключение к серверу(монитор, клавиатура) на всех
tty(ctrl+alt+f1, ctrl+alt+f2, ... ) симптомы одинаковы. через ssh все
абсолютно нормально. Сервиса getty нет, искал в /etc/init.d/getty, чтобы
/etc/init.d/getty restart

29 июня 2016 г., 0:15 пользователь dimas  написал:

> такое на всех tty? tset не поможет? а getty перезапустить?
> по ssh, я так понимаю, шелл работает нормально?
>
>
> 2016-180 21:08 Anatoly Molchanov  wrote:
> > Добрый день, коллеги.
> >
> > Сервер на Debian 7 после 230 дней аптайма показывает черный экран с
> > мигающим курсором. На ввод реагирует смещением курсора, похоже что
> удалось
> > авторизоваться. Сервер, визуально, полностью работоспособен, никакого
> > криминала в логах нет, все сервисы работают штатно. Подскажите,
> пожалуйста,
> > как можно диагностировать?
>
>

Re: Черный экран с курсором

[dimas]

такое на всех tty? tset не поможет? а getty перезапустить?
по ssh, я так понимаю, шелл работает нормально?


2016-180 21:08 Anatoly Molchanov  wrote:
> Добрый день, коллеги.
> 
> Сервер на Debian 7 после 230 дней аптайма показывает черный экран с
> мигающим курсором. На ввод реагирует смещением курсора, похоже что удалось
> авторизоваться. Сервер, визуально, полностью работоспособен, никакого
> криминала в логах нет, все сервисы работают штатно. Подскажите, пожалуйста,
> как можно диагностировать?

Re: [DONE] wml://security/2014/dla-{37,65}.wml

[Vladimir Zhbanov]

On Tue, Jun 28, 2016 at 03:36:16PM +0500, Lev Lamberov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> - --- english/security/2014/dla-37.wml2016-04-09 01:32:21.0 
> +0500
> +++ russian/security/2014/dla-37.wml  2016-06-28 14:01:57.061323842 +0500
> @@ -1,51 +1,52 @@
> - -LTS security update
> +#use wml::debian::translation-check translation="1.3" maintainer="Lev 
> Lamberov"
> +обновление безопасности LTS
>  
> - -Several vulnerabilities were discovered in krb5, the MIT implementation
> - -of Kerberos. The Common Vulnerabilities and Exposures project identifies
> - -the following problems:
> +В krb5, реалиазации Kerberos от MIT, было обнаружено несколько
> +уязвимостей. Проект Common Vulnerabilities and Exposures определяет
> +следующие проблемы:
>  
>  
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2014-4341;>CVE-2014-4341
>  
> - - An unauthenticated remote attacker with the ability to inject
> - - packets into a legitimately established GSSAPI application session
> - - can cause a program crash due to invalid memory references when
> - - attempting to read beyond the end of a buffer.
> + Неаутентифицированный удалённый злоумышленник, способный выполнять 
> инъекцию
> + пакетов в корректно установленную сессию GSSAPI-приложения,
> + может вызывать аварийную остановку программы из-за неправильных 
> указаний областей памяти при
> + попытке чтения за пределами выделенного буфера.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2014-4342;>CVE-2014-4342
>  
> - - An unauthenticated remote attacker with the ability to inject
> - - packets into a legitimately established GSSAPI application session
> - - can cause a program crash due to invalid memory references when
> - - reading beyond the end of a buffer or by causing a null pointer
> - - dereference.
> + Неаутентифицированный удалённый злоумышленник, способный выполнять 
> инъекцию
> + пакетов в корректно установленную сессию GSSAPI-приложения,
> + может вызывать аварийную остановку программы из-за неправильных 
> указаний областей памяти при
> + чтении за пределами выделенного буфера или из-за разыменования
> + null-указателя.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2014-4343;>CVE-2014-4343
>  
> - - An unauthenticated remote attacker with the ability to spoof 
> packets
> - - appearing to be from a GSSAPI acceptor can cause a double-free
> - - condition in GSSAPI initiators (clients) which are using the SPNEGO
> - - mechanism, by returning a different underlying mechanism than was
> - - proposed by the initiator. A remote attacker could exploit this flaw
> - - to cause an application crash or potentially execute arbitrary 
> code.
> + Неаутентифицированный удалённый злоумышленник, способный подделывать 
> пакеты так, что
> + они кажутся исходящими от принимающей стороны GSSAPI, может вызывать 
> состояние двойного
> + освобождения памяти в инициаторах GSSAPI (клиентах), использующих 
> механизм
> + SPNEGO, возвращая базовый механизм, отличный от
> + предложенного инициатором. Удалённый злоумышленник может использовать 
> эту уязвимость
> + для вызова аварийной остановки приложения или потенциального выполнения 
> произвольного кода.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2014-4344;>CVE-2014-4344
>  
> - - An unauthenticated or partially authenticated remote attacker can
> - - cause a NULL dereference and application crash during a SPNEGO
> - - negotiation by sending an empty token as the second or later context
> - - token from initiator to acceptor.
> + Неаутентифицированный или частично аутентифицированный удалённый 
> злоумышленник может
> + вызывать разыменование NULL-указателя и аварийную остановку приложения 
> в ходе согласования
> + SPNEGO путём отправки пустого токена в качестве второго или 
> последующего контекстного
> + токена от инициатора принимающей стороне.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2014-4345;>CVE-2014-4345
>  
> - - When kadmind is configured to use LDAP for the KDC database, an
> - - authenticated remote attacker can cause it to perform an
> - - out-of-bounds write (buffer overflow).
> + Если kadmind настроен на использование LDAP для базы данных KDC, то
> + аутентифицированный удалённый злоумышленник может вызывать запись за
> + пределами выделенного буфера (переполнение буфера).
>  
>  
>  
> - -For Debian 6 Squeeze, these issues have been fixed in krb5 
> version 1.8.3+dfsg-4squeeze8
> +В Debian 6 Squeeze эти проблемы были исправлены в пакете krb5 
> версии 1.8.3+dfsg-4squeeze8
>  
>  
>  # do not modify the following line
> - --- english/security/2014/dla-65.wml2016-04-09 01:32:21.0 
> +0500
> +++ russian/security/2014/dla-65.wml  2016-06-28 15:36:08.493784791 +0500
> @@ -1,90 +1,91 @@
> - -LTS security 

Re: ограничить трафик в час?

[Кузьмин Андрей]

Помнится мне есть такая утила шейпер называется, может с помощью нее все решить 
можно? 

28.06.2016, 11:44, "Artem Chuprina" :
> Eugene Berdnikov -> debian-russian@lists.debian.org @ Tue, 28 Jun 2016 
> 10:59:49 +0300:
>
>  >> Я хочу предоставлять некоторым визитерам своей квартиры гостевой доступ
>  >> в интернет, с ограничением вида "10 мегабайт на хост за два часа".
>  > ...
>  >> Посмотрел на hashlimit у iptables - оно умеет только в секунду.
>
>  > Судя по ману, hashlimit умеет и часы, и даже дни. Однако для этой
>  > задачи он плох тем, что в burst ему можно указать лишь число пакетов,
>  > а не объём трафика.
>
> Я почитал более тщательно. Время он умеет только при количестве
> пакетов. При байтах - только секунду.
>
> С другой стороны, в burst можно указывать байты. В соответствующем
> абзаце это сказано не шибко внятно, но там пример на это есть.
>
> Я вот думаю, может, для простоты сделать
>
> --hashlimit-above 1b/s --hashlimit-burst 10mb --hashlimit-htable-expire 
> 17280 ?
>
> (expire у него в миллисекундах...)
>
> quota тоже интересно, впрочем. Надо поэкспериментировать. С квотой
> только, боюсь, засада в том, что надо на каждый адрес отдельное правило.
> hashlimit хорош тем, что задается одно правило на всю подсеть, а считать
> можно попросить по каждому адресу отдельно.
>
> И задается статически. Я очень люблю свою статическую конфигурацию
> iptables, которая при старте системы поднимается iptables-restore из
> того, что было сохранено iptables-save.

Черный экран с курсором

[Anatoly Molchanov]

Добрый день, коллеги.

Сервер на Debian 7 после 230 дней аптайма показывает черный экран с
мигающим курсором. На ввод реагирует смещением курсора, похоже что удалось
авторизоваться. Сервер, визуально, полностью работоспособен, никакого
криминала в логах нет, все сервисы работают штатно. Подскажите, пожалуйста,
как можно диагностировать?

Re: [DONE] wml://{security/2016/dsa-3607.wml}

[Lev Lamberov]

28.06.2016 20:49, Vladimir Zhbanov пишет:
> On Tue, Jun 28, 2016 at 04:50:52PM +0500, Lev Lamberov wrote:
>> +Ян Хорн из Google Project Zero сообщил, что файловая системе eCryptfs
> систем_а_
>
>> +отключены непривилегированные пользовательские пространства имён. Если 
>> же они включены
>> +локально с помощью kernel.unprivileged_userns_clone sysctl, то это 
>> позволяет
> здесь или sysctl впереди имени можно поставить, или заменить на "с
> помощью системного вызова ..."
>
>> +Тихо Андерсен обнаружил, что в некоторых ситуациях ядро Linux 
>> неправильно
>> +обрабатывает переданные монтирования. Локальный пользователь может
> несмотря на то, что я не вполне понимаю, что имел сказать автор под
> "propagated", я бы сказал "заданные операции монтирования", если
> имеется в виду
> https://bugs.launchpad.net/ubuntu/xenial/+source/linux/+bug/1588056

Исправил. Спасибо!


signature.asc
Description: OpenPGP digital signature

Re: [DONE] wml://{security/2016/dsa-3607.wml}

[Vladimir Zhbanov]

On Tue, Jun 28, 2016 at 04:50:52PM +0500, Lev Lamberov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> - --- english/security/2016/dsa-3607.wml  2016-06-28 15:42:48.0 
> +0500
> +++ russian/security/2016/dsa-3607.wml2016-06-28 16:50:45.321513561 
> +0500
> @@ -1,8 +1,9 @@
> - -security update
> +#use wml::debian::translation-check translation="1.1" maintainer="Lev 
> Lamberov"
> +обновление безопасности
>  
> - -Several vulnerabilities have been discovered in the Linux kernel that
> - -may lead to a privilege escalation, denial of service or information
> - -leaks.
> +В ядре Linux было обнаружено несколько уязвимостей, которые
> +могут приводить к повышению привилегий, отказу в обслуживании или утечкам
> +информации.
>  
>  
>  
> @@ -16,118 +17,118 @@
>   href="https://security-tracker.debian.org/tracker/CVE-2016-3138;>CVE-2016-3138,
>   href="https://security-tracker.debian.org/tracker/CVE-2016-3140;>CVE-2016-3140
>  
> - -Ralf Spenneberg of OpenSource Security reported that various USB
> - -drivers do not sufficiently validate USB descriptors.  This
> - -allowed a physically present user with a specially designed USB
> - -device to cause a denial of service (crash).
> +Ральф Шпенненберг из OpenSource Security сообщил, что различные 
> драйверы USB
> +выполняют недостаточные проверки USB-дескрипторов.  Это
> +позволяет пользователю, имеющему физический доступ к системе, вызывать 
> отказ в обслуживании
> +(аварийная остановка) с помощью специально сформированного 
> USB-устройства.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2016-0821;>CVE-2016-0821
>  
> - -Solar Designer noted that the list poisoning feature, 
> intended
> - -to mitigate the effects of bugs in list manipulation in the
> - -kernel, used poison values within the range of virtual addresses
> - -that can be allocated by user processes.
> +Solar Designer заметил, что возможность отравления списка, 
> предназначенная
> +для уменьшения влияния ошибок при работе со списками в
> +ядре, использует отравленные значения в пределах диапазона виртуальных 
> адресов,
> +которые могут быть выделены пользовательским процессам.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2016-1237;>CVE-2016-1237
>  
> - -David Sinquin discovered that nfsd does not check permissions when
> - -setting ACLs, allowing users to grant themselves permissions to a
> - -file by setting the ACL.
> +Дэвид Синкин обнаружил, что nfsd не выполняет проверку прав доступа 
> при
> +установке ACL, что позволяет пользователям давать себе права доступа
> +к файлу путём установки ACL.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2016-1583;>CVE-2016-1583
>  
> - -Jann Horn of Google Project Zero reported that the eCryptfs
> - -filesystem could be used together with the proc filesystem to
> - -cause a kernel stack overflow.  If the ecryptfs-utils package is
> - -installed, local users could exploit this, via the
> - -mount.ecryptfs_private program, for denial of service (crash) or
> - -possibly for privilege escalation.
> +Ян Хорн из Google Project Zero сообщил, что файловая системе eCryptfs

систем_а_

> +может использоваться вместе с файловой системой proc с целью
> +вызова переполнения стека ядра.  Если в системе установлен пакет 
> ecryptfs-utils,
> +то локальные пользователи могут использовать эту уязвимость с помощью
> +программы mount.ecryptfs_private для вызова отказа в обслуживании 
> (аварийная остановка) или
> +возможного повышения привилегий.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2016-2117;>CVE-2016-2117
>  
> - -Justin Yackoski of Cryptonite discovered that the Atheros L2
> - -ethernet driver incorrectly enables scatter/gather I/O. A remote
> - -attacker could take advantage of this flaw to obtain potentially
> - -sensitive information from kernel memory.
> +Джастин Якоски из Cryptonite обнаружил, что драйвер локальной сети 
> Atheros L2
> +неправильно включает разброс/сбор I/O. Удалённый
> +злоумышленник может использовать эту уязвимость для получения 
> потенциально
> +чувствительной информации из памяти ядра.
>  
>   href="https://security-tracker.debian.org/tracker/CVE-2016-2143;>CVE-2016-2143
>  
> - -Marcin Koscielnicki discovered that the fork implementation in the
> - -Linux kernel on s390 platforms mishandles the case of four
> - -page-table levels, which allows local users to cause a denial of
> - -service (system crash).
> +Марцин Косцельницки обнаружил, что реализация fork в
> +ядре Linux на платформах с архитектурой s390 неправильно обрабатывает 
> ситуацию с
> +четырьмя уровнями таблицы страниц, что позволяет локальным пользователям 
> вызывать отказ
> +в обслуживании (аварийная остановка системы).
>  
>   

[DONE] wml://security/2014/dla-{37,65}.wml

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2014/dla-37.wml  2016-04-09 01:32:21.0 +0500
+++ russian/security/2014/dla-37.wml2016-06-28 14:01:57.061323842 +0500
@@ -1,51 +1,52 @@
- -LTS security update
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+обновление безопасности 
LTS
 
- -Several vulnerabilities were discovered in krb5, the MIT implementation
- -of Kerberos. The Common Vulnerabilities and Exposures project identifies
- -the following problems:
+В krb5, реалиазации Kerberos от MIT, было 
обнаружено несколько
+уязвимостей. Проект Common Vulnerabilities and Exposures 
определяет
+следующие проблемы:
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2014-4341;>CVE-2014-4341
 
- - An unauthenticated remote attacker with the ability to inject
- - packets into a legitimately established GSSAPI application session
- - can cause a program crash due to invalid memory references when
- - attempting to read beyond the end of a buffer.
+ Неаутентифицированный удалённый 
злоумышленник, способный выполнять 
инъекцию
+ пакетов в корректно установленную 
сессию GSSAPI-приложения,
+ может вызывать аварийную остановку 
программы из-за неправильных указаний 
областей памяти при
+ попытке чтения за пределами 
выделенного буфера.
 
 https://security-tracker.debian.org/tracker/CVE-2014-4342;>CVE-2014-4342
 
- - An unauthenticated remote attacker with the ability to inject
- - packets into a legitimately established GSSAPI application session
- - can cause a program crash due to invalid memory references when
- - reading beyond the end of a buffer or by causing a null pointer
- - dereference.
+ Неаутентифицированный удалённый 
злоумышленник, способный выполнять 
инъекцию
+ пакетов в корректно установленную 
сессию GSSAPI-приложения,
+ может вызывать аварийную остановку 
программы из-за неправильных указаний 
областей памяти при
+ чтении за пределами выделенного буфера 
или из-за разыменования
+ null-указателя.
 
 https://security-tracker.debian.org/tracker/CVE-2014-4343;>CVE-2014-4343
 
- - An unauthenticated remote attacker with the ability to spoof packets
- - appearing to be from a GSSAPI acceptor can cause a double-free
- - condition in GSSAPI initiators (clients) which are using the SPNEGO
- - mechanism, by returning a different underlying mechanism than was
- - proposed by the initiator. A remote attacker could exploit this flaw
- - to cause an application crash or potentially execute arbitrary 
code.
+ Неаутентифицированный удалённый 
злоумышленник, способный подделывать 
пакеты так, что
+ они кажутся исходящими от принимающей 
стороны GSSAPI, может вызывать состояние 
двойного
+ освобождения памяти в инициаторах GSSAPI 
(клиентах), использующих механизм
+ SPNEGO, возвращая базовый механизм, 
отличный от
+ предложенного инициатором. Удалённый 
злоумышленник может использовать эту 
уязвимость
+ для вызова аварийной остановки 
приложения или потенциального выполнения 
произвольного кода.
 
 https://security-tracker.debian.org/tracker/CVE-2014-4344;>CVE-2014-4344
 
- - An unauthenticated or partially authenticated remote attacker can
- - cause a NULL dereference and application crash during a SPNEGO
- - negotiation by sending an empty token as the second or later context
- - token from initiator to acceptor.
+ Неаутентифицированный или частично 
аутентифицированный удалённый 
злоумышленник может
+ вызывать разыменование NULL-указателя и 
аварийную остановку приложения в ходе 
согласования
+ SPNEGO путём отправки пустого токена в 
качестве второго или последующего 
контекстного
+ токена 

Re: ограничить трафик в час?

[Artem Chuprina]

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Tue, 28 Jun 2016 
10:59:49 +0300:

 >> Я хочу предоставлять некоторым визитерам своей квартиры гостевой доступ
 >> в интернет, с ограничением вида "10 мегабайт на хост за два часа".
 > ...
 >> Посмотрел на hashlimit у iptables - оно умеет только в секунду.

 >  Судя по ману, hashlimit умеет и часы, и даже дни. Однако для этой
 >  задачи он плох тем, что в burst ему можно указать лишь число пакетов,
 >  а не объём трафика.

Я почитал более тщательно.  Время он умеет только при количестве
пакетов.  При байтах - только секунду.

С другой стороны, в burst можно указывать байты.  В соответствующем
абзаце это сказано не шибко внятно, но там пример на это есть.

Я вот думаю, может, для простоты сделать

--hashlimit-above 1b/s --hashlimit-burst 10mb --hashlimit-htable-expire 
17280 ?

(expire у него в миллисекундах...)

quota тоже интересно, впрочем.  Надо поэкспериментировать.  С квотой
только, боюсь, засада в том, что надо на каждый адрес отдельное правило.
hashlimit хорош тем, что задается одно правило на всю подсеть, а считать
можно попросить по каждому адресу отдельно.

И задается статически.  Я очень люблю свою статическую конфигурацию
iptables, которая при старте системы поднимается iptables-restore из
того, что было сохранено iptables-save.

[DONE] wml://security/2014/dla-1{18,03}.wml

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2014/dla-103.wml 2016-04-09 01:32:21.0 +0500
+++ russian/security/2014/dla-103.wml   2016-06-28 13:43:46.846245762 +0500
@@ -1,76 +1,77 @@
- -LTS security update
+#use wml::debian::translation-check translation="1.4" maintainer="Lev Lamberov"
+обновление безопасности 
LTS
 
- -This security upload has been prepared in cooperation of the Debian 
Kernel,
- -Security and LTS Teams and features the upstream stable release 2.6.32.64 
(see
- -https://lkml.org/lkml/2014/11/23/181;>https://lkml.org/lkml/2014/11/23/181
 for more information for that). It fixes
- -the CVEs described below.
- -Note: if you are using the openvz flavors, please consider three 
things: a.)
- -we haven't got any feedback on them (while we have for all other flavors) b.)
- -so do your test before deploying them and c.) once you have done so, please
- -give feedback to debian-...@lists.debian.org.
+Данное исправление безопасности было 
совместно подготовлено командами Debian Kernel,
+Security и LTS, оно содержит стабильный выпуск 
основной ветки разработки, 2.6.32.64 
(дополнительную
+информацию смотрите по адресу https://lkml.org/lkml/2014/11/23/181;>https://lkml.org/lkml/2014/11/23/181).
 Оно исправляет
+описанные ниже CVE.
+Внимание: если вы используете 
варианты ядра для openvz, то учтите следующее: 
a)
+мы не получили никакого отклика о них (хотя 
мы получили отклики для всех остальных 
вариантов) b)
+поэтому до развёртывания ядра вам следует 
его протестировать, а также c) когда вы 
выполните тестирование,
+сообщите о его результатах в список 
рассылки debian-...@lists.debian.org.
 
- -If you are not using openvz flavors, please still consider b+c :-)
+Если вы не используете варианты ядра для 
openvz, то всё равно учтите пункты b+c :-)
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2012-6657;>CVE-2012-6657
 
- -Fix the sock_setsockopt function to prevent local users from being able to
- -cause a denial of service (system crash) attack.
+Исправление функции sock_setsockopt, чтобы 
локальные пользователи не могли
+вызывать отказ в обслуживании (аварийная 
остановка системы).
 
 https://security-tracker.debian.org/tracker/CVE-2013-0228;>CVE-2013-0228
 
- -Fix a XEN priviledge escalation, which allowed guest OS users to gain 
guest OS
- -priviledges.
+Исправление повышения привилегий XEN, что 
позволяет пользователям гостевых систем 
получать права
+гостевых систем.
 
 https://security-tracker.debian.org/tracker/CVE-2013-7266;>CVE-2013-7266
 
- -Fix the mISDN_sock_recvmsg function to prevent local users from obtaining
- -sensitive information from kernel memory.
+Исправление функции mISDN_sock_recvmsg, чтобы 
локальные пользователи не могли получить
+чувствительную информацию из памяти 
ядра.
 
 https://security-tracker.debian.org/tracker/CVE-2014-4157;>CVE-2014-4157
 
- -MIPS platform: prevent local users from bypassing intended PR_SET_SECCOMP
- -restrictions.
+Платформа MIPS: исправление, чтобы 
локальные пользователи не могли обходить 
ограничения
+PR_SET_SECCOMP.
 
 https://security-tracker.debian.org/tracker/CVE-2014-4508;>CVE-2014-4508
 
- -Prevent local users from causing a denial of service (OOPS and system 
crash)
- -when syscall auditing is enabled .
+Исправление, чтобы локальные 
пользователи не могли вызвать отказ в 
обслуживании (OOPS и аварийная остановка 
системы)
+в том случае, когда включены аудит 
системных вызовов.
 
 https://security-tracker.debian.org/tracker/CVE-2014-4653;>CVE-2014-4653
 
 https://security-tracker.debian.org/tracker/CVE-2014-4654;>CVE-2014-4654
 https://security-tracker.debian.org/tracker/CVE-2014-4655;>CVE-2014-4655
 
- -Fix the ALSA control implementation to prevent local users from causing a
- -denial of service attack and from obtaining sensitive information from kernel
- -memory.
+Исправление реализации управления ALSA, 
чтобы локальные пользователи 

[DONE] wml://security/2014/dla-{81,27}.wml

[Lev Lamberov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2014/dla-27.wml  2016-04-09 01:32:21.0 +0500
+++ russian/security/2014/dla-27.wml2016-06-28 13:23:17.831857308 +0500
@@ -1,55 +1,55 @@
- -LTS security update
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+обновление безопасности 
LTS
 
- -Fix various denial of service attacks:
+Исправление различных атак, направленных
 на вызов отказа в обслуживании:
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2014-3487;>CVE-2014-3487
 
- -  The cdf_read_property_info function does not properly validate a stream
- -  offset, which allows remote attackers to cause a denial of service
- -  (application crash) via a crafted CDF file.
+  Функция cdf_read_property_info неправильно 
выполняет проверку отступа
+  потока, что позволяет удалённым 
злоумышленникам вызывать отказ в 
обслуживании
+  (аварийная остановка приложения) с 
помощью специально сформированного файла 
в формате CDF.
 
 https://security-tracker.debian.org/tracker/CVE-2014-3480;>CVE-2014-3480
 
- -  The cdf_count_chain function in cdf.c in does not properly validate
- -  sector-count data, which allows remote attackers to cause a denial of
- -service
- -  (application crash) via a crafted CDF file.
+  Функция cdf_count_chain в cdf.c неправильно 
выполняет проверку
+  данных о числе секторов, что позволяет 
удалённым злоумышленникам вызывать отказ
+  в обслуживании (аварийная остановка 
приложения) с помощью специально 
сформированного файла в формате CDF.
 
 https://security-tracker.debian.org/tracker/CVE-2014-3479;>CVE-2014-3479
 
- -  The cdf_check_stream_offset function in cdf.c relies on incorrect
- -  sector-size data, which allows remote attackers to cause a denial of 
service
- -  (application crash) via a crafted stream offset in a CDF file.
+  Функция cdf_check_stream_offset в cdf.c использует 
неправильные
+  данные о размере сектора, что позволяет 
удалённым злоумышленникам вызывать отказ 
в обслуживании
+  (аварийная остановка приложения) с 
помощью специально сформированного 
отступа потока в файле CDF.
 
 https://security-tracker.debian.org/tracker/CVE-2014-3478;>CVE-2014-3478
 
- -  Buffer overflow in the mconvert function in softmagic.c allows remote
- -  attackers to cause a denial of service (application crash) via a crafted
- -  Pascal string in a FILE_PSTRING conversion.
+  Отказ в обслуживании в функции mconvert в 
softmagic.c позволяет удалённым
+  злоумышленникам вызывать отказ в 
обслуживании (аварийная остановка 
приложения) с помощью специально
+  сформированной строки на языке Pascal при 
преобразовании FILE_PSTRING.
 
 https://security-tracker.debian.org/tracker/CVE-2014-0238;>CVE-2014-0238
 
- -  The cdf_read_property_info function in cdf.c allows remote attackers to
- -  cause a denial of service (infinite loop or out-of-bounds memory access) 
via
- -  a vector that (1) has zero length or (2) is too long.
+  Функция cdf_read_property_info в cdf.c позволяет 
удалённым злоумышленникам
+  вызывать отказ в обслуживании 
(бесконечный цикл или доступ за границы 
выделенного буфера памяти) с помощью
+  вектора, который (1) имеет нулевую длину, 
либо (2) слишком длинный.
 
 https://security-tracker.debian.org/tracker/CVE-2014-0237;>CVE-2014-0237
 
- -  The cdf_unpack_summary_info function in cdf.c allows remote attackers to
- -  cause a denial of service (performance degradation) by triggering many
- -  file_printf calls.
+  Функция cdf_unpack_summary_info в cdf.c позволяет 
удалённым злоумышленникам
+  вызывать отказ в обслуживании (ухудшение 
производительности) путём выполнения 
большого
+  количества вызовов file_printf.
 
 https://security-tracker.debian.org/tracker/CVE-2014-0207;>CVE-2014-0207
 
- -  The cdf_read_short_sector function in cdf.c allows remote attackers to
- -  cause a 

Re: ограничить трафик в час?

[Eugene Berdnikov]

On Tue, Jun 28, 2016 at 10:14:30AM +0300, Artem Chuprina wrote:
> Я хочу предоставлять некоторым визитерам своей квартиры гостевой доступ
> в интернет, с ограничением вида "10 мегабайт на хост за два часа".
...
> Посмотрел на hashlimit у iptables - оно умеет только в секунду.

 Судя по ману, hashlimit умеет и часы, и даже дни. Однако для этой
 задачи он плох тем, что в burst ему можно указать лишь число пакетов,
 а не объём трафика.
-- 
 Eugene Berdnikov

Re: ограничить трафик в час?

[Eugene Berdnikov]

On Tue, Jun 28, 2016 at 10:14:30AM +0300, Artem Chuprina wrote:
> Я хочу предоставлять некоторым визитерам своей квартиры гостевой доступ
> в интернет, с ограничением вида "10 мегабайт на хост за два часа".
> Именно за два часа, меня устроит, если он их все использует за минуту,
> но потом ему доступ отрубят.
...
> Есть у нас что-нибудь, что может за два часа считать?  Ну и сбрасывать
> насчитанное со временем, понятно.

 Для iptables есть модуль quota, можно наполнять "ведро" каждые два часа.
 Или каждый час по половинке, и т.д.
-- 
 Eugene Berdnikov

Re: ограничить трафик в час?

[Vasiliy P. Melnik]

у меня сто мегабит дома, микротик позволяет с пол пинка поднять сеть
гостевую, выделил туда 5 мегабит. Естественно даже не заметно.

Не, если чисто из академического интереса - писать какую-то обвязку для
айпитейблсов, считать трафик ну и принимать какие-то решения на этом
основании. Только не понимаю какое отношение рейт трафика имеет к
ограничению по объему, 10 мегабайт может быть и за одну минуту, а потом
просто не надо трафика

28 июня 2016 г., 10:14 пользователь Artem Chuprina 
написал:

> Хмутро.
>
> Я хочу предоставлять некоторым визитерам своей квартиры гостевой доступ
> в интернет, с ограничением вида "10 мегабайт на хост за два часа".
> Именно за два часа, меня устроит, если он их все использует за минуту,
> но потом ему доступ отрубят.
>
> (Идея в том, что есть некий интернет-задрот, который приходит отнюдь не
> серфить по интернету, но у него типа рабочее пространство в облаке;
> меня, в общем, устроит, если он будет работать в облаке, но не устроит,
> если его винда начнет через меня слать свою телеметрию, спам/вирусы
> (буде он ее заразит) или на автопилоте, увидев интернет, качать
> торренты.  Ну и...  Не сумел ограничить аппетиты винды - живи без
> облака.  Сумел - можешь пользоваться облаком.  Интернет-задрот ты или
> где?)
>
> Отдельная подсеть, роутер - дебиан.
>
> Посмотрел на hashlimit у iptables - оно умеет только в секунду.  tc,
> кажется, тоже.  На крайний случай, конечно, и в секунду можно ужать, но
> получится либо очень медленно, либо потенциально очень много за два
> часа-то.
>
> Есть у нас что-нибудь, что может за два часа считать?  Ну и сбрасывать
> насчитанное со временем, понятно.
>
>

ограничить трафик в час?

[Artem Chuprina]

Хмутро.

Я хочу предоставлять некоторым визитерам своей квартиры гостевой доступ
в интернет, с ограничением вида "10 мегабайт на хост за два часа".
Именно за два часа, меня устроит, если он их все использует за минуту,
но потом ему доступ отрубят.

(Идея в том, что есть некий интернет-задрот, который приходит отнюдь не
серфить по интернету, но у него типа рабочее пространство в облаке;
меня, в общем, устроит, если он будет работать в облаке, но не устроит,
если его винда начнет через меня слать свою телеметрию, спам/вирусы
(буде он ее заразит) или на автопилоте, увидев интернет, качать
торренты.  Ну и...  Не сумел ограничить аппетиты винды - живи без
облака.  Сумел - можешь пользоваться облаком.  Интернет-задрот ты или
где?)

Отдельная подсеть, роутер - дебиан.

Посмотрел на hashlimit у iptables - оно умеет только в секунду.  tc,
кажется, тоже.  На крайний случай, конечно, и в секунду можно ужать, но
получится либо очень медленно, либо потенциально очень много за два
часа-то.

Есть у нас что-нибудь, что может за два часа считать?  Ну и сбрасывать
насчитанное со временем, понятно.