Очень странно работает HDMI. Сценарий 1) Включаем ТВ, Включаем ПК - все работает. Сценарий 2) Включаем ТВ, Включаем ПК - Выключаем ТВ, Включаем - все, ТВ - сигнал больше не видит, причем то пишет нет сигнала, то неподдерживаемый видеоформат.

Причем так себя система ведет не на разных портах «не постоянно» HDMI, т.е. сегодня глючит HDMI порт 1, завтра он работает нормально, но глючит HDMI 4.

При этом - пробовал другой ПК - он нормально дружит со всеми портами HDMI - никаких проблем нету, с теми же кабелями и т.д. Пробовал ОСы разные Windows 7, Debian 7 , Ubuntu 14.04 - от ос\установленных драйверов - кажется ситуация не зависит.

Причем, если на ПК сделать ребут, то HDMI не возвращается, а если выключить, подождать пару сек, включить, то HDMI сигнал идет. Из всех ОС нашел только в Debian инфу - много записей с сислоге HDMI status: Codec=0 Pin=3 Presence_Detect=1 ELD_Valid=1

Т.е. соединяться они пытаются, но что-то происходит? Что? Чего ему не хватает? Может быть ему не совсем хватает питания?

P.s. ПК это сервер HP N54L с установленной в PCI-E видеокартой Sapphire HD 6450. Такая конфигурация у «других» работает на ура.

«Другой ПК» - это десктопник i7 с вендой. Телек.. ну не самый новый Philips 42pfl9664h.

Точно знаю, что приставка к телеку тоже бывает «подлагивает»(её нужно выключить и включить), но сбивает столку то, что вот есть ПК, который совсем не глючит с этим телеком.

Куда копать?

На хосте(debian) заведен софтверный рейд md0(sda+sdb), с помощью KVM поднята гостевая система под NAS (Xpenology). Пробовал в качестве Storage Device передавать /dev/md0, но гостевая система лишь предлагает его отформатировать. Пробовал передавать /dev/sda и /dev/sdb - гостевая система в целом нормально видит жесткие диски, видит рейд, предложила правда исправить, но после исправления ничего не отвалилось. Но появляется вопрос - насколько корректно передавать /dev/sda - /dev/sdb ? нельзя ли передать массив как один диск?

Если передавать просто оба диска /dev/sda и /dev/sdb - можно ли в хостовой системе оставлять mdadm в режиме монитора? И как гарантированно запретить монтирование этого массива в хостовой системе(чтобы ни в коем случае диски не оказались примонтированными и там и там, ибо, если я правильно понимаю есть конкретный риск запороть файловую систему)?

Уважаемые товарищи! Уже какой день бьюсь над одной проблемой - при объеме письма больше 8192 символов - время отправки письма увеличивается в 25 раз! Я начал курить исходные коды и выяснил, что утечка где-то в этой функции

static int
read_message_data_smtp(FILE *fout)
{
debug_printf("  function called \n");

int ch_state = 0;
register int ch;
register int linelength = 0;


while ((ch = (receive_getc)()) != EOF)
  {
  if (ch == 0) body_zerocount++;
  switch (ch_state)
    {
    case 0:                             /* After LF or CRLF */
    if (ch == '.')
      {
      ch_state = 3;
      continue;                         /* Don't ever write . after LF */
      }
    ch_state = 1;

    /* Else fall through to handle as normal uschar. */

    case 1:                             /* Normal state */
    if (ch == '\n')
      {
      ch_state = 0;
      body_linecount++;
      if (linelength > max_received_linelength)
        max_received_linelength = linelength;
      linelength = -1;
      }
    else if (ch == '\r')
      {
      ch_state = 2;
      continue;
      }
    break;

    case 2:                             /* After (unwritten) CR */
    body_linecount++;
    if (linelength > max_received_linelength)
      max_received_linelength = linelength;
    linelength = -1;
    if (ch == '\n')
      {
      ch_state = 0;
      }
    else
      {
      message_size++;
      if (fout != NULL && fputc('\n', fout) == EOF) return END_WERROR;
      if (ch != '\r') ch_state = 1; else continue;
      }
    break;

    case 3:                             /* After [CR] LF . */
    if (ch == '\n')
      return END_DOT;
    if (ch == '\r')
      {
      ch_state = 4;
      continue;
      }
    ch_state = 1;                       /* The dot itself is removed */
    break;

    case 4:                             /* After [CR] LF . CR */
    if (ch == '\n') return END_DOT;
    message_size++;
    body_linecount++;
    if (fout != NULL && fputc('\n', fout) == EOF) return END_WERROR;
    if (ch == '\r')
      {
      ch_state = 2;
      continue;
      }
    ch_state = 1;
    break;
    }

  /* Add the character to the spool file, unless skipping; then loop for the
  next. */

  message_size++;
  linelength++;
  if (fout != NULL)
    {
    if (fputc(ch, fout) == EOF) return END_WERROR;
    if (message_size > thismessage_size_limit) return END_SIZE;
    }
  }

/* Fall through here if EOF encountered. This indicates some kind of error,
since a correct message is terminated by [CR] LF . [CR] LF. */

return END_EOF;
}

Для личных и не очень целей частенько пользуюсь Hamachi, но постоянные проблемы возникающие при работе с ним порядком надоели. Хочется, чтобы без труда для клиентов можно было организовать прямой соединение в локалку. Родилась идея использовать один из своих инетовских серверов под это дело. Осталось придумать как это организовать. Первым в голову пришло - организовать VPN сервер. Во первых не ясно насколько это верное решение? Во вторых стал копать в сторону развертки VPN сервера на FreeBSD и я ужаснулся от могущественного разнообразия способов организации этого дела: много слов вроде VPN, OpenVPN, mpd, pf. Подскажите, какой путь мне стоит избрать?

Подскажите, как на маршрутизаторе прописать так, чтобы пользователи при коннекте на host1:port1 выдавалось host2:port2 ? в голове полная каша после прочтения мануалов :(

Есть такая проблема: разные пользователи видят разные права доступа точнее otheruser@server ~]$ ls -al | grep etc drwxr-x--x 2 1000 1002 3584 Oct 22 13:12 etc

в тоже время от рута: [root@server /]# ls -al | grep etc drw-r--r-- 36 root wheel 1024 Nov 19 14:17 etc

соответственно ни к одному файлу из /etc доступа тоже не имеем от других пользователей. Как вообще возможно чтобы они видели разные права доступа? как разрешить в таком случае доступ?

[otheruser@server ~]$ getfacl etc/ #file:etc/ #owner:1000 #group:1002 user::rwx group::r-x other::--x

[root@server /]# getfacl etc/ #file:etc/ #owner:0 #group:0 user::rw- group::r-- other::r--

Глупый вопрос. но сервак упал во время выполнения этой комманды. Пятая точка подсказывает - рекурсия. Логика твердит, что все ок. Что я сделал не так?

Можно ли както замедлить отправку писем?