Re: Проблема с icedove
01.04.2013 08:34, Ivan Zavarzin пишет: > debian squeeze amd64 > Icedove 3.0.11 > > Внезапно в одном из аккаунтов появился такой глюк: > При попытке скачать почту по POP3 выходит окошко: >> The folder Inbox is full, and can't hold any more messages. To make room for >> more messages, delete any old or unwanted mail and compact the folder. С _сервера_ удали часть почты или расширь лимит. -- Best regards, Mikhail - WWW: http://www.antmix.pp.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Проблема с icedove
Mikhail A Antonov: > 01.04.2013 08:34, Ivan Zavarzin пишет: >> debian squeeze amd64 >> Icedove 3.0.11 >> >> Внезапно в одном из аккаунтов появился такой глюк: >> При попытке скачать почту по POP3 выходит окошко: >>> The folder Inbox is full, and can't hold any more messages. To make room >>> for more messages, delete any old or unwanted mail and compact the folder. > С _сервера_ удали часть почты или расширь лимит. > > Удалил на сервере - не помогло. Окошко вылазит это еще до того, как клиент начинает устанавливать сетевое соединение. Так что проблема похоже не в сервере,а что-то с клиентом случилось. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51595159.9040...@lavabit.com
Re: Немного о Gnus.
On Вск, Мар 31 2013 at 23:51, Dmitrii Kashin wrote: > 1) При получении больших вложений nnml просто зависает. Точнее, > работает, но скачивает их через час по чайной ложке. Можно ли как-то > улучшить поведение Gnus при получении больших вложений? Не зависает. «Большие» у вас — это сколько? Каким образом происходит «получение» — копирование из локального спула, POP3, IMAP ? > 2) Можно ли заставить nnrss наботать быстрее? Сейчас он тормозит > страшно, поэтому я от него просто отказался и пользуюсь newsbeuter. Опять же, не «страшно». То есть, не страшнее, чем какая-нибудь настольная читалка. > 3) Я знаю про хоткей M-s и даже читал документацию [1], однако поиск, к > большому моему сожалению, производится по письму-сырцу (raw article), > которое довольно часто зашифровано посредством base64. И разумеется, > поиск по на русском из-за этого не работает, разве что я сначала > переведу шаблон поиска в base64. А можно ли в Gnus искать по телам > сообщений на русском без таких ухищрений? Поиск по тексту сообщений на русском языке работает прямо «из коробки». > 4) Хотелось бы, чтобы Gnus при нахождении ссылки открывал её посредством > w3m при нажатии, скажем, RET. Не подскажете ли как лучше реализовать > данный функционал? Например, через '(browse-url-browser-function (quote w3m-browse-url)) Вообще, есть такое ощущение, что у вас слишком сложный файл конфигурации. Попробуйте, пожалуйста, воспроизвести всё вышеописанное с умолчальной конфигурацией. То есть с пустыми пользовательскими конфигами Emacs и Gnus. -- ~dd -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eheu8whp@africa.home.dd
Re: Немного о Gnus.
Dmitry Derjavin writes: > On Вск, Мар 31 2013 at 23:51, Dmitrii Kashin wrote: > >> 1) При получении больших вложений nnml просто зависает. Точнее, >> работает, но скачивает их через час по чайной ложке. Можно ли как-то >> улучшить поведение Gnus при получении больших вложений? > > Не зависает. «Большие» у вас — это сколько? Каким образом происходит > «получение» — копирование из локального спула, POP3, IMAP ? Большие - это с вложениями на несколько мегабайт. Получение через pop3. Вот выдержка из ~/.gnus: -- cut -- (setq gnus-secondary-select-methods '((nnml "") (nntp "news.aioe.org")) ) (setq mail-sources '( (directory :path "/home/freehck/Mail/mail/misc") (pop :server "pop.gmail.com" :port 995 :user "free...@gmail.com" :password "xxx" :stream ssl))) -- cut -- >> 2) Можно ли заставить nnrss наботать быстрее? Сейчас он тормозит >> страшно, поэтому я от него просто отказался и пользуюсь newsbeuter. > > Опять же, не «страшно». То есть, не страшнее, чем какая-нибудь > настольная читалка. Я не понимаю, что значит "не страшно". Мне не нравится, что newsbeuter забирает все мои фиды за минуту, в то время как nnrss колупается все десять. >> 3) Я знаю про хоткей M-s и даже читал документацию [1], однако поиск, к >> большому моему сожалению, производится по письму-сырцу (raw article), >> которое довольно часто зашифровано посредством base64. И разумеется, >> поиск по на русском из-за этого не работает, разве что я сначала >> переведу шаблон поиска в base64. А можно ли в Gnus искать по телам >> сообщений на русском без таких ухищрений? > > Поиск по тексту сообщений на русском языке работает прямо «из коробки». Ну да. А вот попробуйте произвести поиск в этой самой рассылке, скажем, по слову "Рахматуллин". Я вот, например, ожидал найти offlist-сообщение[1], случайно пересланное собеседником сюда. Но Вы его не найдете. Не найдете, потому что содержимое письма целиком в base64. >> 4) Хотелось бы, чтобы Gnus при нахождении ссылки открывал её посредством >> w3m при нажатии, скажем, RET. Не подскажете ли как лучше реализовать >> данный функционал? > > Например, через '(browse-url-browser-function (quote w3m-browse-url)) > > Вообще, есть такое ощущение, что у вас слишком сложный файл конфигурации. > Попробуйте, пожалуйста, воспроизвести всё вышеописанное с умолчальной > конфигурацией. То есть с пустыми пользовательскими конфигами Emacs и Gnus. Эээ... Спасибо, что-то не хочется. С моим конфигом все в порядке. Если хотите, могу приложить его. [1] https://lists.debian.org/debian-russian/2013/02/msg00079.html -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9pitk6m@ws00.freehck.ru
Re: Проблема с icedove
> При попытке скачать почту по POP3 выходит окошко: > > The folder Inbox is full, and can't hold any more messages. To make room > > for more messages, delete any old or unwanted mail and compact the folder. > > В других аккаунтах проблемы нет. Преположу что файл inbox ~2G? -- С уважением, Сергей Москвичёв. xmpp: uks...@ya.ru
Re: Проблема с icedove
Сергей Москвичёв: >> При попытке скачать почту по POP3 выходит окошко: >>> The folder Inbox is full, and can't hold any more messages. To make room >>> for more messages, delete any old or unwanted mail and compact the folder. >> >> В других аккаунтах проблемы нет. > > Преположу что файл inbox ~2G? > > Больше 4-х, но почему-то до вчерашнего дня все прекрасно работало. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5159b2b0.1020...@lavabit.com
Re: Проблема с icedove
Ivan Zavarzin: > Сергей Москвичёв: >>> При попытке скачать почту по POP3 выходит окошко: The folder Inbox is full, and can't hold any more messages. To make room for more messages, delete any old or unwanted mail and compact the folder. >>> >>> В других аккаунтах проблемы нет. >> >> Преположу что файл inbox ~2G? >> >> > Больше 4-х, но почему-то до вчерашнего дня все прекрасно работало. И самое удивительное, сколько я не удаляю из него письма и не архивирую (они переносятся в другой файл), почему то его размер не уменьшается... Странно это. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5159bc38.4060...@lavabit.com
Re: Проблема с icedove
1 апреля 2013 г., 20:56 пользователь Ivan Zavarzin < ivan_zavar...@lavabit.com> написал: > Ivan Zavarzin: > > Сергей Москвичёв: > >>> При попытке скачать почту по POP3 выходит окошко: > The folder Inbox is full, and can't hold any more messages. To make > room for more messages, delete any old or unwanted mail and compact the > folder. > >>> > >>> В других аккаунтах проблемы нет. > >> > >> Преположу что файл inbox ~2G? > >> > >> > > Больше 4-х, но почему-то до вчерашнего дня все прекрасно работало. > > И самое удивительное, сколько я не удаляю из него письма и не архивирую > (они переносятся в другой файл), почему то его размер не уменьшается... > Странно это. > > strace?
Re: Проблема с icedove
Aleksandr Sytar: > 1 апреля 2013 г., 20:56 пользователь Ivan Zavarzin < > ivan_zavar...@lavabit.com> написал: > >> Ivan Zavarzin: >>> Сергей Москвичёв: > При попытке скачать почту по POP3 выходит окошко: >> The folder Inbox is full, and can't hold any more messages. To make >> room for more messages, delete any old or unwanted mail and compact the >> folder. > > В других аккаунтах проблемы нет. Преположу что файл inbox ~2G? >>> Больше 4-х, но почему-то до вчерашнего дня все прекрасно работало. >> >> И самое удивительное, сколько я не удаляю из него письма и не архивирую >> (они переносятся в другой файл), почему то его размер не уменьшается... >> Странно это. >> >> > strace? > > strace что-то особо не хочет показывать ничего после того, как клиент загрузиться. Загрузился клиент, появляется последняя запись в выводе strace wait4(-1, , а что дальше уже клиентам пытаешься делать, ничего не выводиться. Обнаружил, что хотя я перегонял средствами icedove письма из Inbox в трэш и архив, сам файл Inbox не изменялся (открыл его less'ом - все что было там есть). Создал новый Inbox командой cat (нулевой), пытаюсь скачать почту, ничего не скачивается. Предупреждение о том что мало место при этом не выскакивает. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5159c0c6.5020...@lavabit.com
Re: Виртуализация
01.04.2013 08:30, Stanislav Vlasov пишет: > Очень большое количество компонентов, требуемых для GFS2, взаимосвязь > которых хреново настраивается. > Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер > менее, чем на три машины делать уже точно не стоит. Понятно. Значит, стоит остановиться на OCFS2. >> Так, насчёт СХД, первый вопрос. > >> Что имею: >> 1. Два сервера. В каждом 6 SATA на 1 Тб. >> 2. В них Core2 с Vt-d. >> 3. Пару особо старых одноюнитовых серверов без виртуализации ( к тому, что >> предыдущие 2 - большие и диски перекрутить не получится, а ВМ где-то надо >> запускать). > Не совсем понял, кто на ком стоял, но ладно, разберёмся в процессе. 2 сервера в каждом 6 x 1 Тб SATA. CPU с Vt-x (VT-d нет, сегодня смотрел). В них 3 сетевых интерфейса. На них сейчас Fedora. Их под СХД. Помимо них, есть старые одноюнитовые HP ProLiant 2006 года с двумя сказями в 70 с чем-то Гб каждый. Сейчас на них RHEL. Они когда-то были резервом, но сейчас настройки прикладного ПО на них неактуальны (как и железо). Это из того, что есть в стойке. На них, естественно, VT нет. Там по два старых ксеона на каждом. Также, валяется ещё один HP с б`ольшим количеством SCSI дисков (но тоже маленьких, наверное до 1 Тб, в сумме, не дотянет). Коммутатор, пока что, найти не удалось. > Хотя, если имелось ввиду, что много дисков должно быть на тех же > серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки > немного подумать над реорганизацией. Бекапы должны лежать отдельно от > рабочих серверов. Я и хочу отдельно... Но процессоры на старых серверах намного хуже, чем на тех, что под бэкапы (2 старых Xeon против Core2 Duo). > Желательно даже на расстоянии и в сейфе. Увы, нереально (реально разнести их по разным серверным, но слишком проблематично). Они стоят в соседних стойках. Но, физическое разделение, в принципе, не ко мне. > К тому же, при создании бекапов будет довольно приличная дисковая > нагрузка, процессор будет в основном в состоянии iowait, что повлияет > на работу виртуалок. Так ведь диски все давно с DMA (процессор будет ждать прерывания). Или всё-равно? >> 4. Коммутатор (говорят, что возможно найти лишний). > Для надёжности лучше два. Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор. >> Что требуется: >> 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно >> ограничиться только настройками (думаю, что систему там смогут поставить). >> Под >> это вполне хватит 8 Тб. >> 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза >> хватит 2 Тб. > Нормальное ТЗ, вобщем-то. > К бекапам еще бы ленточек... Георгиевских или вы про стриммеры? :-) >> Что хочу: >> 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для >> образов ВМ. > DRBD поверх раздела в 2Тб. > Как вариант - сделать этот раздел на стареньких серверах, объединить > их в DRBD и потом отдавать по iscsi весь том на оба сервера > виртуализации с одного из серверов. На старых серверах нет места. Там SCSI не более, чем на 200-500 Гб (на тех, что сейчас, вообще 100 с чем-то Гб). > При отказе - воспользоваться heartbeat для переключения ip-адреса > iscsi и master-slave в drbd. >> 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервных >> копий и базы данных (в т.ч. Zabbix). >> 3. Иметь возможность менять конфигурацию СХД "на лету" (например, убрать >> часть >> дисков из ненадёжного хранилища и создать ещё одно надёжное). > С DRBD настолько на лету не выйдет, проверено. Только переконфигурация > томов, созданных поверх DRBD. А с Lustre? Я могу убрать два диска из Lustre и создать из них DRBD? >> Как хочу реализовать (пока только задумки): >> I. Надёжное хранилище. >> 1. Выделить 2 диска на каждом сервере под RAID-0. >> 2. Объединить в RAID-1, используя DRDB. >> 3. ФС - OCFS2. > 3 - может быть clvm (clustered lvm). Возможно, будет на несколько > процентов быстрее. В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM? > >> II. Ненадёжное хранилище. >> Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI >> или лучше >> AoE. Либо использовать, например, Lustre. > > AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом > плане менее капризен. Какие проблемы? > Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли. Вай? По-идее, под бэкапы и хочу. Но почему не под рабочий раздел? Если бы оставить только LustreFS, конфигурация бы сильно упростилась... >> А стоит ли вообще выдумывать со всякими "надёжными-ненадёжным хранилищами"? >> Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? >> Ведь >> ей не нужен DRBD? > Не нужен, но по iops оно значительно медленнее, чем iscsi. Т.е., для виртуалок не подойдёт..? >> Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет >> пропадать впустую. > А с какой целью оно надо? > Что на локальном разделе, что на удалённом - монопольно пробр
Re: Виртуализация
2 апреля 2013 г., 0:36 пользователь "Артём Н." написал: > 01.04.2013 08:30, Stanislav Vlasov пишет: > > Очень большое количество компонентов, требуемых для GFS2, взаимосвязь > > которых хреново настраивается. > > Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер > > менее, чем на три машины делать уже точно не стоит. > Понятно. Значит, стоит остановиться на OCFS2. > Это проще. > > Хотя, если имелось ввиду, что много дисков должно быть на тех же > > серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки > > немного подумать над реорганизацией. Бекапы должны лежать отдельно от > > рабочих серверов. > Я и хочу отдельно... Но процессоры на старых серверах намного хуже, чем на > тех, > что под бэкапы (2 старых Xeon против Core2 Duo). Мда... > > К тому же, при создании бекапов будет довольно приличная дисковая > > нагрузка, процессор будет в основном в состоянии iowait, что повлияет > > на работу виртуалок. > Так ведь диски все давно с DMA (процессор будет ждать прерывания). Или > всё-равно? > А это неважно. Время случайного доступа никто не отменял. > >> 4. Коммутатор (говорят, что возможно найти лишний). > > Для надёжности лучше два. > Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен > коммутатор. Хм... Разве что сумеете обеспечить связь "каждый с каждым" без него, причём с двойным резервированием. > >> Что требуется: > >> 1. Сохранять резервные копии с машин внутренней сети. Для начала > возможно > >> ограничиться только настройками (думаю, что систему там смогут > поставить). Под > >> это вполне хватит 8 Тб. > >> 2. Иметь доступное хранилище для образов виртуальных машин. Под них за > глаза > >> хватит 2 Тб. > > Нормальное ТЗ, вобщем-то. > > К бекапам еще бы ленточек... > Георгиевских или вы про стриммеры? :-) Таки про стримеры. С одной м :-) > >> Что хочу: > >> 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать > для > >> образов ВМ. > > DRBD поверх раздела в 2Тб. > > Как вариант - сделать этот раздел на стареньких серверах, объединить > > их в DRBD и потом отдавать по iscsi весь том на оба сервера > > виртуализации с одного из серверов. > На старых серверах нет места. Там SCSI не более, чем на 200-500 Гб (на > тех, что > сейчас, вообще 100 с чем-то Гб). Мда... Извращение... >> 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для > резервных > >> копий и базы данных (в т.ч. Zabbix). > >> 3. Иметь возможность менять конфигурацию СХД "на лету" (например, > убрать часть > >> дисков из ненадёжного хранилища и создать ещё одно надёжное). > > С DRBD настолько на лету не выйдет, проверено. Только переконфигурация > > томов, созданных поверх DRBD. > А с Lustre? > Я могу убрать два диска из Lustre и создать из них DRBD? > Можно и так. Но опять же - в оффлайне. > >> Как хочу реализовать (пока только задумки): > >> I. Надёжное хранилище. > >> 1. Выделить 2 диска на каждом сервере под RAID-0. > >> 2. Объединить в RAID-1, используя DRDB. > >> 3. ФС - OCFS2. > > 3 - может быть clvm (clustered lvm). Возможно, будет на несколько > > процентов быстрее. > В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на > cLVM? Нет, clvm не требуется кластерная фс. И оно не заменяет drbd, а живёт поверх. Просто это lvm, работающий в кластере, когда тома лвм доступны всем узлам кластера. > > > >> II. Ненадёжное хранилище. > >> Тут задумок пока мало. Либо создать RAID0 и пробросить через > iSCSI или лучше > >> AoE. Либо использовать, например, Lustre. > > > > AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом > > плане менее капризен. > Какие проблемы? При бондинге двух сетевых карт и на клиенте и на сервере скрость передачи упёрлась в одну сетевую карту. > > Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли. > Вай? > По-идее, под бэкапы и хочу. > Но почему не под рабочий раздел? > Если бы оставить только LustreFS, конфигурация бы сильно упростилась... iops. Виртуалки тоже хотят писать на диск, причём часто. > >> А стоит ли вообще выдумывать со всякими "надёжными-ненадёжным > хранилищами"? > >> Может, возможно ограничиться LustreFS (чтобы не плодить лишних > наворотов)? Ведь > >> ей не нужен DRBD? > > Не нужен, но по iops оно значительно медленнее, чем iscsi. > Т.е., для виртуалок не подойдёт..? Угу, я тестировал как-то... Для текущих задач с iops порядка полутора тысяч на один сервер - не подойдёт. В тестах на таком же железе и 2x1Гб сети выходило порядка нескольких сотен в пределе. iscsi на этом же стенде упёрся в диски по iops. Скорость чтения/записи отличалась на несколько процентов (оба явно упирались в сеть), так что тут разночтений нет. > >> С другой стороны, я ведь могу использовать > >> паравиртуализованные ОС без потери производительности? > > Как обычно, вобщем-то. > Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на > старых HP > Proliant)? Только для линуксов. > Ну я понял, что БД, вс
