argon bulletin board
Пловдивски университет => free ping => Темата е започната от: Емил Дойчев в 28.06.2012, 17:10:48
-
Изключително рядко си позволявам да стартирам нова тема в този форум. От 10 години имам регистрация тук и се оказа, че моите нови теми са 4. Позволявам си след дълго мислене все пак да стартирам 5тата си тема защото съм крайно разочарован от услугата "електронна поща" на университета. Дълго мислих не защото не бях сигурен дали съм разочарован, а защото не бях убеден, че тук е мястото да изказвам разочарованието си. Все пак нещата, които ще споделя бих искал да получат някаква публичност и предпочетох форумът.
Убеден съм, че хората, които използват електронната поща на ПУ са много добре запознати с проблемите, които възникнаха след миграцията към Microsoft Exchange, който между другото, е един много добър пощенски сървър. Разбира се при всяка промяна от подобен мащаб (над 600 акаунта) проблемите са неизбежни, но има неща, които не биваше да се случват и такива, които отдавна трябваше да са отстранени. Ето какво според мен трябваше да се избегне:
- Полумъртвата услуга по време на миграцията. Процеса траеше около 4 дни, които бяха почивни за страната. Обаче тези дни не бяха почивни за останалата част на света. В ПУ се развива предимно научна дейност и голяма част от преподавателите са в непрекъснати контакти с колеги в страната и чужбина по различни поводи. Проблемът беше, че през тези 4 дни хостът на mail.uni-plovdiv.bg не приемаше писма и връщаше код за невъзстановима грешка, който отказваше изпращащите e-mail сървъри да повторят опитите си за изпращане на писмата (обикновено такива опити се правят в продължение на 5 дни). И какво се случва когато човек очаква потвърждение за участие в конференция в този период, примерно?
Далеч по-добре щеше да е да се блокира SMTP порта и mail сървъра въобще да не отговаря, отколкото напълно да отказва подателите.
- Проблемите с SPF настройките. Това е много добра защита срещу разпространението на спам от името на университетски акаунти към други e-mail сървъри. С други думи SPF защитата дава възможност на e-mail сървърите да могат да разпознаят кога едно писмо, което се твърди че се подава от акаунта x@uni-plovdiv.bg, наистина идва от пощенския сървър на ПУ. Преди години се разпространяваха лъжливи писма от името на уважавани преподаватели в ПУ. Сега ситуацията е дори по-зле, защото неправилната SPF настройка блокира получаването на писма изпратени от mail.uni-plovdiv.bg до огромно количество e-mail сървъри, които прилагат SPF защита. В тези случай почти веднага след изпращане на писмото се връща съобщение с подобен текст:
failed to meet SPF requirements
Този проблем е от повече от месец и не е нормално да продължава.
- Липсата на елементарна spam защита. Съществуват много smap защити, но за съжаление по нищо не личи пощенският сървър да разполага с някаква.
- Липсата на HTTPS достъп. Използването на web клиента по HTTP никак не е за препоръчване. Как се прихваща парола от http хедър учат и студентите от ФМИ.
- Свалянето на прикачени файлове, чрез web клиента. Това си е цяло приключение. Без значение какъв е типа на файла нито пък името му той се сваля винаги с име attachment.ashx (поне под Google Chrome).
- Честите сривове. Напоследък пощенският сървър никакъв го няма (днес например го нямаше за около 10 часа). Справка: http://netmon.uni-plovdiv.bg/smokeping.fcgi?target=http.poshta_SMTP
Според мен това са нещата, които направиха така, че да не може да се разчита на новата електронна поща на ПУ. А при загуба на доверие няма значение колко е добър самият пощенски сървър. Което е жалко. Тъжното е, че преди време когато Тодор Чаушев от ФМИ предлагаше пощата на ПУ да мигрира в Google Mail, аз бях "възмутен", а сега трябва да призная, че това е било по-добрият вариант. В никакъв случай не смятам, че е правилно ПУ да се откаже от поддържането на собствен пощенски сървър защото ПУ е достатъчно голяма организация, с хиляди служители и студенти и е срамно да не може да поддържа собствена услуга за електронна поща. Още повече, че обучава IT специалисти, което предполага, че има нужният капацитет. Но Google Mail пред сегашното положение определено е за предпочитане.
И тъй като служителите и преподавателите в ПУ имат нужда от e-mail, който да ги идентифицира с университета, и на който да могат да разчитат, съвсем естествено се появи алтернатива, която аз вътрешно не одобрявам, но в крайна сметка ако няма нужда няма да има и алтернативи. Алтернативата е описана тук: https://projects.uni-plovdiv.net/projects/services/wiki/Mail. Работи и вече доста хора са мигрирали към този пощенски сървър. Регистрацията е изключително опростена тъй като се ползва Focus акаунт и само се указва името на пощенската кутия.
Не искам този пост да се приеме за агитация за алтернативният пощенски сървър. Както казах, аз лично не го одобрявам. По-скоро ми се иска някой отговорен да вземе отношение по проблемите и да даде някаква яснота в краткосрочен план. Защото алтернативи винаги ще се намерят, но не мисля че това е правилният начин.
-
Също пиша много рядко тук, просто няма кой да го прочете :)
Пощата или там както се нарича тая услуга която е всичко друго но не и поща в момента, прилича по-скоро на спортен тотализатор! С колегите вече се хващаме на бас кой ще може да се логне и кой не. Но за съжаление през последните дни (от неделя) отново вероятността да се логнеш е доста по-малка от колкото на споменатият спорт тото :wink:
Всички колеги са на мнение, че когато пощата си беше администрирана от стария админ (той си знае кой е) всичко беше наред. В момента всички преминават на други доставчици на услуги по простата причина че не е сигурен за своята кореспонденция и трябва да хвърля боб да види дали ще получи или няма да получи дали ще се логне или няма да се логне. Въпросът не е в това че има лек хаос, по-скоро щом веднъж се притесниш след това и супер стабилна да стане услугата винаги ще имаш едно на ум, че може да се прецака нещо в най-кофти момента! Това го пиша от гледна точка на обикновен юзър.
То било защото пощата не работила както трябва и била пред срив.....хм аз пък в момента се чувствам раздвоен преди съм нямал ни-ка-кви проблеми за толкова години, а сривове имаме в момента?
А това, че се минава на MS Exchange да се надяваме, че не е заради MS double-click certified administration :) а един ден ще видим и Exchange Sync директ пуш-а за мобилни у-ва. Което в момента не е планирано да се направи :drunk:
Както и да е аз не ползвам пощата като основна от 7 години, но й пожалавам здраве и щастие, както и здрави нерви и валерян за ползващите я :-D
Поздрави!
ПП
аа забравих да кажа и пълното затъмнение за нас потребителите! Ама в сайта било казано - да ама след колко време след като подпалиха телефоните се сетиха да постнат съобщението? Както и в момента - никои нищо не знае какво става и ще го огрее ли днес :)
Нищо лично :)
-
Хайде и аз да се включа по темата, понеже е наистина гореща напоследък в ПУ. Двете мнения от по-горе точно отговарят на наблюденията ми от последния месец в ПУ. Наистина има много емоция по този случай, но целта ми с този пост ще е да поохладя малко страстите и споделя моята гледна точка и моето мнение - както аз виждам нещата.
С мрежата на ПУ се занимавам доста всеотдайно от 1999-2000 година, след като родилия я - Пламен Йорданов напусна. Първите услуги, които пуснах от ентусиазъм тогава бяха поща на ХФ, DHCP за вътрешната мрежа (до тогава бяха със статични адреси), прокси, този форум... Наследих и тогавашната поща, на Slackware/sendmail - машина, която беше и gateway към Цифрови системи, а също и DNS. През 2007 обединих пощите на ХФ и ПУ в едно (именно подмяната на тази машина/услуга се коментира в този топик). До момента, в който внезапно бях уволнен от новото ПУ ръководство през февруари 2012 мрежата/услугите, за които отговарях бяха стабилни и аз не се посрамих в техническия смисъл на думата. Натрупах доста опит, който сега ми помага в различни направления.
Въпреки всичко допуснах много грешки, резултата на които се чете в двата поста по-горе. За периода от 2000 г. насам си позволих да се възгордея с мизерните си начални знания и умения и имайки голяма отговорност и власт над мрежата. Презрях доста отзивчиви хора, само защото не знаят нещо, което съм прочел предната вечер. Изградената гордост ме скара с колеги и приятели. Всичко това беше премесено с много неправилни административни хватки и пр. В резултат почти през целия период бях мразен и outsider, напълно неподкрепян от ръководството на ПУ и сочен с пръст за всички мрежови недъзи до последно и дори все още.
Смисъла на тези писания може да се заключи в следното: който е безгрешен, нека пръв да хвърли камъка. За съжаление днес напълно разкаян от това си минало поведение осъзнавам, че тези принципи на гордост, отмъщение, злословие, хули и клевета са сред всички слоеве в ПУ, държавата, дори и личните ни отношенията... за съжаление.
"Всичко е суета и гонене на вятър"! Всичко това е пагубно - жажда за пари, за власт, за титли, за почит... кой помни днес вчерашните злодеи, а какво ни дава основание, че някой утре ще помни нас... и с какво?
В този контекст съм убеден, че имам принос в лошата услуга за ел. поща напоследък, най-малкото че съм провокирал това неправилно отношение през годините. Днес съм готов да подам ръка за помощ, но за съжаление жънем друга сеитба, а помощ не се търси.
-
Не знам как да подходя, но мисля, че трябва да се преодолеят тези негативизми и търсения на вина (оправдания и обвинения от всички страни към всички останали) и да се работи в екип, за отстраняване на проблема с пощата. Бих се радвал, ако това стане прецедент и се наложи за в бъдеще (екипността, не проблемите).
По-конкретно, за съжаление аз нямам опит с email сърверите, но Атанас Терзийски е очевидно че има, Емил Дойчев има, екипът на ФМИ със сигурност има нужните познания. И аз бих могъл да почета или потърся информация и литература по въпроса, има и форуми и хора с аналогични проблеми. Нека екипът на УИЦ да анализира своите възможности и ресурси (човешки предимно) и да поиска официална помощ - ще му я окажем.
Основната грешка на екипа на УИЦ в конкретната ситуация с преминаването към MSE беше точно и основно държането в неведение на потребителите и на колегите с по-висок опит. Можеше да се направи нещо като лог или project management страница, където да се уведомяват потребителите за текущото състояние. Пределно ми е ясно, че колегите от УИЦ не саботират системата и се стараят свръх силите си, за да се реши проблема, но когато няма информираност и осведоменост, възникват догадки, обвинения, слухове.
-
Кучетата си лаят, керванът си върви... В последните 19 часа mail.uni-plovdiv.bg не приема писма:
Sat 2012-06-30 00:27:26: Attempting SMTP connection to [194.141.96.231:25]
Sat 2012-06-30 00:27:26: Waiting for socket connection...
Sat 2012-06-30 00:27:27: * Winsock Error 10061 The other host is either down or has refused to connect with you at that IP and/or on that port.
http://netmon.uni-plovdiv.bg/smokeping.fcgi?displaymode=n;start=2012-06-29%2011:10;end=2012-07-01;target=http.poshta_SMTP
През 2012 г. това е смешно и несериозно.
Пълното информационно затъмнение изглежда се смята за удачен подход за справяне с мрънкащи потребители.
Някой знае ли какъв е официалният ред за получаване на информация относно тази материя? Защото тук очевидно няма да получим отговор на нищо, а и съм сигурен, че в длъжностната характеристика на никой не пише, че трябва да знае къде се намира форума и да отговаря в него. От страницата на УИЦ http://uni-plovdiv.bg/pages/index/51/ не става ясно към кого може да се адресират такива, очевидно несериозни, въпроси. Може би трябва да се мине по някакъв "канален" ред, който е дефиниран в някой забутан документ?
Чудя се всъщност ректор, зам. ректори и декани не използват ли този начин за комуникация? Ако на мен като един обикновен асистент липсата на електронна поща в 21 век създава затруднения то за тях това би трябвало да е още по-голям проблем. Или ръководството може би смята, че услугата електронна поща на ПУ не е необходимост, а лукс който служители и преподаватели не заслужават.
-
Не знам. Очевидно телефоните са начин за контакт само в работно време. Емайлите от същият домейн в момента са 'неподходящ' начин също.
Използва се емайла, Емо и има много оплаквания и се създават проблеми. Има и офиц. доклади и запитвания по въпроса. И на Академичен съвет се е дискутирало.
Просто трябва да им се помогне някак да се преодолее този проблем в тази и другите проблемни в момента мрежови услуги - независимо кой и защо е виновен. Кажете да се съберем и да умуваме - ще го настроим и оправим бързо, ако се организираме. Никой няма да претендира после за пари, за гордост, за благодарност. Просто се губи реномето на самата институция ПУ, не на УИЦ или на някой си отделен човек. Смешно е да се общува с АБВ мейли, макар че аз лично (както Веско Баев) от 7-8 години ползвам dir.bg и gmail.com за основни емайл адреси, обаче имах преди forward на университетския емайл и един акаунт с обратен подател университетският адрес. Дори настоях да ми се направи alias enkov, за да не съм с псевдонима ми (от 1993-4-та ми е това shark at uni-plovdiv.bg), за да звучи по-престижно за институцията, когато го публикувам по статии, конференции и по визитната ми картичка.
Не знам как да се процедира официално - доклад с приложена статистика и оплакване също не знам ще има ли нужният ефект. Не излезе ли от самият УИЦ инициативата - не става. А те се сърдят защо не ги подкрепяме. Подкрепяме ги - но искаме и услугата. Вчера пуснах до цялата катедра едно предложение за нови правила за дипломиране (оформяне на дипломни работи) - е, защо нямам отговор, познайте... Всъщност, успях да го пратя, преди срива. И 2 колеги ми писаха в скайпа, защото РОР3 учудващо работи и са го прочели писмото ми. Опит за отговор през същия сървер в последните 19-20 часа очевидно не е можел да бъде успешен.
Нека колегите от УИЦ не го приемат като критика, но просто не става така. Давайте да се организираме и да го видим какво е. Ако пък знаят какъв е проблема и не го решават... тогава е друго.
-
Засега SMTP тръгна. За другите проблеми - ще чакаме те да ни попитат или поканят за помощ и съдействие. Пожелавам им искрен успех и бързо решаване на всички проблеми.
-
Това ако е тръгване: http://netmon.uni-plovdiv.bg/smokeping.fcgi?displaymode=n;start=2012-07-02%2014:40;end=2012-07-02%2015:40;target=http.poshta_SMTP
Не се получават писма дори между акаунти на ПУ.
Утре и в сряда са защитите на дипломантите във ФМИ. Трудно е рецензентите да си пратят рецензиите на научните ръководители. А как ще ги разпратим след това до дипломантите навреме, така че да могат да се подготвят за защитата не знам. Явно наистина ще хвърляме боб дали това недоносче ще работи или пък ще ползваме смешни акаунти в свободни сървъри.
Абсолютен срам.
Пощенската услуга е може би най-старата електронна услуга, която се предоставя по принцип. С нея ПУ не може да се справи, а се говори за фантасмагории като Пловдивски електронен университет. Като спре да ме е срам пред студентите ще започна да се смея.
-
Както всички и аз сърбам попарата на новата система за e-mail вече над месец.
Според мен при тази "миграция" бяха нарушени поне 4-5 основни принципа на администрацията на подобен род услуги:
1. Ако работи - не го пипай. (е понякога трябва да се пипа за да се дадат нови възможности, но аз не виждам нищо ново, а само липса на някои от старите възможности, както и потребители тичащи в паника по коридорите и питащи се защо им няма пощата т.е. не защо не работи и не могат да пратят мейл, а къде им е кореспонденцията трупана с години)
2. Информирай (информация за подмяната и възможни проблеми в периода на миграция не се слага една седмица след, а поне една седмица преди това).
3. Първо пробвай (т.е. Не пипай директно "production" сървъра).
4. Трябва да имаш капацитет - компютри, пари, хора, знания. (очевидно такъв липсва или по-точно някой се опитва да свърши работата сам)
5. Мейл услуга без добър SPAM филтър е по-лошо и от никаква услуга. (като имаме липса или зле настроени SPF, rDNS, DKIM и други подобни и нещата стават още по-зле за услугата като цяло)
6. и т.н. и т.н.
Направо може да направим спецкурс във ФМИ, в който да се изучава само тази "миграция" т.е. в стил "не правете така" (нито в къщи, нито на работа).
Ако аз бях "админа" отговорен за тази "миграция" щях, ако не да се обеся на някой UTP кабел (най-добре Cat5e :wink: ), то поне да си подам оставката.
Заключение: Срам/SPAM, Позор, НЕПрофесионализъм, Аматьорска работа, ...
ПП. Съвсем отделен въпрос е доколко M$ Exchange Server e добър избор, колко струва и т.н. Както казаха колегите и златен да е като не се направи да работи добре това какво ни грее.
ПП1. Ако съм бил твърде саркастичен, извинете. Дано никой да не се е засегнал.
ПП2. Понеже може някой да каже, че само критикувам без да разбирам или че това е много сложно т.н. затова казвам предварително: Правил съм подобни миграции на мейл сървъри и мога да ви уверя, че ако всичко си подготвиш е въпрос на минути пропадане на услугата, което потребителите няма да забележат, защото се прави във време, в което услугата е най-слабо натоварена и както каза Емил, ако сървъра не отговаря 1-2 часа дори няма и да се загуби поща, защото другите сървъри ще я пратят пак след няколко часа. Дори потребителя трябва да разбере за смяната (ако не е прочел съобщението за промяна) само по новия по-шарен интерфейс.
-
Май е редно да поздравим екипа, борещ се с mail server-a като прасе с тиква. Вече има 24 часа непрекъсната работа: http://netmon.uni-plovdiv.bg/smokeping.fcgi?displaymode=n;start=2012-07-04%2019:34;end=2012-07-05%2019:34;target=http.poshta_SMTP
Както е казал Конфуций - "И най-дългото пътешествие започва с първата крачка." Е първата крачка май е направена. Да се надяваме, че следващите крачки (spam защита, SPF, https, работещи правила за пренасочване) ще станат в обозримо бъдеще. Въпреки, че според мен са неща, които се конфигурират в рамките на един работен ден (максимум два ако се прекали с бирата).
И не на последно място мисля, че колегите в УИЦ трябва да преосмислят отношението си когато става въпрос за услуги използвани от стотици души. Определено трябва да има някакъв механизъм за информиране. Проблемите са нормално нещо и винаги ще ги има, но ще е много по-спокойно и за тях ако информират по някакъв начин потребителите за ситуацията около големите (над 1 час) сривове. Също и за планираните подобрения. Може би ще спрем да "лаем" ако знаем какви са намеренията и сроковете относно следващите стъпки. В тази връзка ако гордостта не им попречи могат да погледнат http://projects.uni-plovdiv.bg (инсталация на http://www.redmine.org/). Освен за управление на развитието на проекти, предоставя и много удобен механизъм за връзка с потребителите (bug reports, проследяване на грешките), публикуване на новини и т.н. Една такава система би намалила до минимум напрежението и недоволството (може би неоправдано понякога, но как да разберем?) сред потребителите.
-
Мда, пощата изглежда се стабилизира! :y:
Премисляйки цялата ситуация, с 12 годишен опит в поддръжката на стария меил ми идват някои идеи, които искам да споделя.
На първо място нека всички знаем, че това е невероятен стрес за технически отговорните лица. Толкова несигурна услуга за толкова дълъг период от време, с толкова много въвлечени гневни потребители си е изключително неприятно, независимо от всички останали обстоятелства.
Мисля, че при цялата процедура по прехвърляне се потъпкаха ред добри практики, нещо, което категорично не оправдавам. Всичко това генерира страшно много нерви на всички въвлечени. Потребителите си мислят какво ли не, администраторите (вероятно), че никой не оценя усилията им, а такива има и то много, ако и да липсва добър резултат.
Ето основните грешки, както аз разбирам нещата:
- А. Защо се налага такава колосална промяна?
Прочетох в официални доклади за нова функционалност, модерни неща и други общи приказки, но истина е, че на мен не ми е ясно? Очаквах да има (1) Добър анализ на ситуацията, какво не е наред със старата и как то евентуално би се подобрило с новата поща? (2) Допитване до потребителите. Както винаги съм казвал администраторите са слуги на потребителите и правенето на услуги не е самоцелно. Ако 90% от потребителите не искат нова поща, какво би оправдало такива рокади? (3) Широк форум на който да се реши. И нека приемем оттук надолу, че такова решение за промяна е взето!
- Б. Планиране и прозрачно преминаване от стар към нов сървър/услуга.
Под прозрачно разбирам никой от потребителите да не забележи промяната, освен ако не реши да чукне някакъв линк "пробвай новата web поща тук". Излишно е да обяснявам, че всичко това е възможно с малко по-добро планиране:
- ESMTP Postfix --> Microsoft ESMTP MAIL (същия протокол, порт и криптиране/сертификат);
- Dovecot IMAP --> MS IMAP (същия протокол, порт и криптиране/сертификат);
- Dovecot POP3 --> MS POP3 (същия протокол, порт и криптиране/сертификат);
- същата квота (стария меил беше само около 60-70GB потребителски данни);
- squirrelmail (старата web поща) се подкарва и връзва локално на новия IMAP;
- филтри, алиаси, политики и т.н. "финни" настройки.
Едно напълно отречено техническо беше да се нулират с ЕГН всички потребители. Видимо, е че всичко е вкарвано на ръка, но в този случай новата услуга можеше да работи успоредно за тест, да оставим, че можеше да се програмира логика за прекодиране на паролите. Във Фокус това го правихме няколко пъти с една безобидна подкана за логване в системата. Изключително важно е да се има впредвид при такава операция и компетенцията, времето и броя на хората от техническия екип.
- В. Информираност и връзка с потребителя по време на целия процес.
Това беше казано по-горе от emil и А.Пенев. Аз си го представям като обяснение с текст, стъпки във времето за целия период какво е направено и какво се очаква до 100% приключване. Преди време, когато един колокейшън център на БТК се запали в София и изгоряха машините на dir.bg се впечатлих от пълната информираност и на всеки етап какво се прави. Това наистина прави потребителите съпричастни на операцията дори, а не да хулят и се нервят.
Иска ми се да чуя в крайна сметка колко "струва" всичко това, както и каква е прогнозата за uptime на услугата за следващите 12 месеца. Какво се постигна в крайна сметка съобразно плана от т. А по-горе? Видимо е, че страшно много хора се отдръпнаха от тази услуга и по мое мнение те биха се доверили отново на новата поща може би след дълъг безпроблемен период. Не на последно място кой и как може да поеме отговорност за всичко това?
Подобна процедура би следвало да се обмисля за всякакъв род мрежови дейности... и не само. Ако това се направи, всичко друго е въпрос на няколко команди (грубо казано). Ако не се направи може да е безкраен цикъл от проби, грешки и много емоция.
Искам да завърша поста си с две интересни притчи:
(1) Всеки път на човека е прав в очите му;
(2) Пътят на безумния е прав в собствените му очи, но който е мъдър, слуша съвети.
-
Тъй като не съм напълно осведомен за всички страни на настоящата тема, ще се опитам да отговоря (поне частично) на някои от поставените и разискваните въпроси.
Понякога, колкото и да се планира, настъпват изненади. Ще разгледам няколко групи въпроси/проблеми.
1. Прехвърлянето на пощата от старият към новият сървър и тестването на резултата в Exchange инсталацията.
Това бе планирано (до колкото ми е известно) да се осъществи в рамките на няколко неработни дни. Някои от причините това да не стане незабележимо от потребителите са:
а) Промяната на паролите се е наложила като следствие от новият метод за идентификация в пощенският сървър, който ползва Active Directory. Това дава възможност за използването на един и същ акаунт за достъп до различни (настоящи и бъдещи) услуги, които се/ще се предлагат;
б) Част от проблемите със сървъра след пускането в експлоатация, вероятно са били свързани с неправилно поведение на хоста на виртуалните машини (за заинтересованите - непредвидими и нерегулярни BSODs). Това усложнение е довело до периодичен downtime, преди идентифицирането и отстраняването на проблема.
Понастоящем се работи по конфигурирането на втори сървър-хост на виртуални машини с Exchange, и включването им към Hub Transport сървъра, което ще доведе до още по-висок процент на uptime и надеждност на услугата.
2. Защо Exchange, а не X / Y / Z?
Не възнамерявам да адвокирам или защитавам вече взетото от съответните университетски звена решение. Тук може да се получи огромен спор който да прерасне до равнище Windows срещу Linux или затворен срещу отворен код. Но ще спомена някои от нещата, които идват наготово с Exchange Server, и не са толкова лесни (или не могат да се реализират) в други пощенски сървъри:
a) не само поща - тясната интеграция на задачите, бележките, календарната и контактна информация с Microsoft Outlook, посредством MAPI;
б) използването на "push" нотификации и ActiveSync за синхронизиране на тази информация с мобилни устройства (iPhone, Android, PalmOS и др.);
в) надеждна, бърза и зряла транзакционна база от данни (Extensible Storage Engine) за съхранение на потребителските данни.
Искам отново да отбележа, че не искам да водя до създаването на спор за това кой е по-по-най. Не съм участвал във вземането на това решение и не се смятам за специалист по пощенските сървъри. Целя единствено да хвърля малко светлина върху вероятните причини довели до този избор.
3. Относно проблемите с информираността.
На сайта на университета бе пусната новина за предстоящото планираното преминаване към новият пощенски сървър ( http://uni-plovdiv.bg/news/index/70/ ).
След този срок в действителност има период на "информационно затъмнение". Последвалите проблеми с някои от пощенските кутии, bsods и вероятно други неща за които не знам най-вероятно са довели до големият downtime на услугата. Възниква въпроса, кой отговаря за информираността и прозрачността на дейностите в ПУ? Истината е, че университета няма развит отдел за управление на взаимоотношенията с потребителите. Дори да има система която да позволява подобен вид услуга, не съществува специализиран, натоварен с тази задача, персонал в университета който да я обслужва. А ако всеки почне да пише за всичко което прави има голяма вероятност да настъпи хаос и да се отиде в другият, вече все по-често срещан, вид дезинформиране - прекалено много информация (Information Overload). Аз съм 'за' използването на всякакви средства за увеличаване на прозрачността и информираността на студентите и преподавателите в ПУ, но този проблем е практически невъзможно да се реши само с писането на програми - необходимо е сформирането на съответното звено.
4. Състояние на другите настоящи проблеми.
Състоянието на някои от изложените в предишни постове проблеми или липсващи функционалности е следното:
а) Спам защита – в процес на настройване;
б) липсата на HTTPS достъп – предстои закупуването на trusted сертификат, с който да се защитят тази и други услуги на университета. Това е задача с висок приоритет;
в) свалянето на прикачени файлове – работи под Firefox и IE, има проблем с именуването на файла под Opera, Chrome и Safari (възможно е и други, тези тествах). Проблема е известен и има поправки за него. Ще бъде решен при скорошно планирано инсталиране на съответните поправки (hotfix).
Може да съм пропуснал нещо, но най-вероятно отговорът ще е подобен на горните – работи се по въпроса. От кой и кога – това е свързано с графика на хората които в момента поддържат тази услуга. Факт е, че университета не разполага с голям човешки ресурс за подобен вид дейности. Това не значи обаче, че когато дадена услуга изпадне в подобна ситуация, трябва някой да направи алтернативна, неоторизирана такава. Какво ще постигне това, освен две стъпки назад, заличаване на направеното до момента, създаването на проблеми при бъдещата необходима синхронизация на двете пощенски услуги и допълнителното цялостно объркване на потребителите? Какво ще стане ако още някой пусне собствена версия на услугата?
Университетската поща е точно това – една единна услуга, която да се ползва от целият университет.
Не съм в позиция, а и не възнамерявам да оборвам критиките, засягащи теми от вида на „срам“, „позор“, „загуба на доверие“ и т.н., защото това не е конструктивна, а деструктивна критика. Няма да се опитвам да интерпретирам тези и други изказвания по адрес на университета и неговите служители от други негови служители.
-
Няма да пиша 100 реда този път, просто ще кажа, че подкрепям мненията на Емил Дойчев и Александър Пенев (м/у другото, кефи ме, че си обявяваме имената публично и заемаме лична позиция, не анонимна - не става дума за гефикс, Митко го знаем и него).
Разбира се, че се работи по нещата и се изчистват едно по едно. Това не намалява срамът, позорът и липсата на отговорност, защото минаха вече 40 дена, за такъв срок дори душите на умрелите вече са приключили земният си път и са във вечен покой, но не и многострадалната ни поща.
Не искаме технически оправдания, технически термини и прочие алабализми - защо, как и ама хъма. Така се случи - ок, случи се вече. Както се каза - иска се ясна позиция: колко струва това, как ще се развива занапред, някакви срокове и етапи и прогреса им да се сложат публично (нека не е Redmine, нека е MS Project Web App). Information overload е лошо. но се получи Information blackout (и продължава). И много моля, не се оправдавайте, че били известени всички - 99% си ползваха пощата отделно от веб сайта на ПУ - т.е. трябваше 15 дни по-рано емайл до всички. Ето, Гугъл ме уведомиха с мейл (както и в самата услуга в страницата й), че iGoogle се терминира след 3 месеца. Така направиха и за Google Powermeter. И това е и начинът. Вече всички минаха на алтернативен емайл. Не е никаква загуба, но е жалко, че се получи не толкова от ен на брой загубени емайли, а от НЕИЗВЕСТНОСТТА докога ще продължи и КОГА ПАК ще се случи. Помня, как Атанас Терзийски преди време беше супер експресно повикан от почивката си на морето (преди 5-6 г), за да оправи пощата, защото било ужасен фал, не можело така, не можело да се изчака до утре...
Пак ще кажа, пожелаваме успех, предлагаме помощ и искрено желая да има повече информация по въпроса - не само за пощата. Има и много други наболели проблеми - мрежата в Пед. Факултет, wifi осигуреността в цялото ПУ (eduroam, освен че се прекрати, малко и не ми допадаше, имаше проблеми с достъпа на някои мобилни устройства към него - сложни настройки на сертификатите и радиус сървера), довършването/смяната на главният веб сайт на ПУ - работа има за екипа на УИЦ, което е прекрасно - няма да останат без работни места. Понеже е криза, няма и да е лесно (нито е оправдано) да се изискват нови работни места там, без обоснована нужда.
-
Не искам да коментирам излишно по темата, понеже нямам време да следя форума.
Искам само да споделя една снимка от телефона си - http://kovachev.info/uploads/2012-05-30%2011.06.26.jpg (http://kovachev.info/uploads/2012-05-30%2011.06.26.jpg). Ясно се вижда датата на която е направена, а това е стария пощенски сървър. Малко преди миграцията пощата започна да се държи странно и да се рестартира, да си маунтва партипъните с read права, като след repair на fs проблема продължаваше.
-
Е, все пак не бях прав - оказа се, че форумът се чете и от колегите в УИЦ, въпреки че нямат време да отговарят.
Ще ми се да направя няколко коментара на поста на гефикс, на когото благодаря, че се опита да хвърли малко светлина в тъмнината. Тъй като реално не знам кой е, ще се опитам да съм внимателен защото не искам да засегна никого.
2. Защо Exchange, а не X / Y / Z?
Не възнамерявам да адвокирам или защитавам вече взетото от съответните университетски звена решение. Тук може да се получи огромен спор който да прерасне до равнище Windows срещу Linux или затворен срещу отворен код.
За това си прав! Аз не мисля, че проблемът е във вида на email сървъра, а в това до колко той е най-удачен като се имат предвид познанията на екипа, който го поддържа. Аз разбира се не знам какви хора са включени в този екип и с какви познания са. И не ми е работа да знам. Това е нещо, обаче, което трябва да знае този, който ръководи екипа. Погледнато отстрани нещата не изглеждат добре.
3. Относно проблемите с информираността.
На сайта на университета бе пусната новина за предстоящото планираното преминаване към новият пощенски сървър ( http://uni-plovdiv.bg/news/index/70/ ).
Тук леко не съм съгласен. Формално си прав, но тази новина беше толкова полезна колкото даването на мигач в момента на извършване на маневрата. Ако продължа с аналогията - идеята в употребата на мигачите не е да ни предпази от глоби, а да информира останалите участници в движението за намеренията ни така, че да могат другите да съобразят своите действия. Т.е. това е нещо, което се прави предварително. Публикуваната новина беше по-скоро регистрация на факт, а не предупреждение и не помогна на никого с нищо.
Възниква въпроса, кой отговаря за информираността и прозрачността на дейностите в ПУ? Истината е, че университета няма развит отдел за управление на взаимоотношенията с потребителите...
...необходимо е сформирането на съответното звено.
Това е доста пресилено и честно казано ми звучат като думи на човек с ръководна длъжност в университета, който се опитва да използва случая за други цели. Едва ли е нужно назначаването на паразити, които да се грижат да информират потребителите на дадена услуга, след като те могат да бъдат информирани чрез самата услуга. Да не говорим, че информирането на това паразитно звено за това какво да информира потребителите ще коства не по-малко усилия на колегите в УИЦ отколкото директно да пуснат една новина по подходящ начин в подходящо време.
4. Състояние на другите настоящи проблеми.
Състоянието на някои от изложените в предишни постове проблеми или липсващи функционалности е следното:
а) Спам защита – в процес на настройване;
Честно, колко време трябва за да се настрои връзка с два-три black list сървъра? 30-40 дни явно не са достатъчни.
В интерес на истината аз не получавам спам. Вероятно защото никъде не съм публикувал e-mail адресът ми от акаунта в пощенският сървър на ПУ. В интерес на същата истина обаче съм свидетел и на другата ситуация - email адрес, добре познат в публичното пространство поради участията си на много конференции в чужбина. Спамът там е в такова количество, че акаунтът на практика е неизползваем. Получават се писма дори с подател - същият акаунт (което разбира се с нормални SPF настройки няма да го има). От това си правя извода, че едва ли има настройка за black list сървъри.
в) свалянето на прикачени файлове – работи под Firefox и IE, има проблем с именуването на файла под Opera, Chrome и Safari (възможно е и други, тези тествах). Проблема е известен и има поправки за него. Ще бъде решен при скорошно планирано инсталиране на съответните поправки (hotfix).
Благодаря за разяснението. Ще си инсталирам FF за да мога да свалям файловете по нормален начин.
...Факт е, че университета не разполага с голям човешки ресурс за подобен вид дейности.
Да си дойдем на думата. И за това съм съгласен с теб.
По всичко личи, че някой захапа по-голяма хапка отколкото са възможностите му. Човек трябва да може да преценява както собствените си възможности, така и тези на хората които ръководи и да не ги натоварва с неща, които са непосилни. Явно е, че проблемът не е точно в хората, които работят в УИЦ. До колкото знам те са натоварени с много неща. От самото начало това си е чисто управленска грешка.
Не съм в позиция, а и не възнамерявам да оборвам критиките, засягащи теми от вида на „срам“, „позор“, „загуба на доверие“ и т.н., защото това не е конструктивна, а деструктивна критика. Няма да се опитвам да интерпретирам тези и други изказвания по адрес на университета и неговите служители от други негови служители.
И тук си прав. Ти сам казваш, че си в страни от нещата. Нека това да го коментира този, който е отговорен за едномесечните мъки с електронната поща. Както се казва "рибата се вмирисва от главата". И това, че 10 дни никой от УИЦ не посмя да напише някакъв отговор тук подкрепя съмнението, че проблемът не е точно в хората там.
Това не значи обаче, че когато дадена услуга изпадне в подобна ситуация, трябва някой да направи алтернативна, неоторизирана такава. Какво ще постигне това, освен две стъпки назад, заличаване на направеното до момента, създаването на проблеми при бъдещата необходима синхронизация на двете пощенски услуги и допълнителното цялостно объркване на потребителите? Какво ще стане ако още някой пусне собствена версия на услугата?
Университетската поща е точно това – една единна услуга, която да се ползва от целият университет.
Ще се повторя:
...ако няма нужда няма да има и алтернативи.
Ще споделя и собственият си опит. Преди години (може би 9-10) пуснах e-mail сървър към една лаборатория. Какви са били мотивите вече не помня. Тогава се получиха проблеми поради факта, че не знаех нищо за поддръжката и конфигурирането на e-mail сървър. Проблемите бяха сериозни тъй като част от IP адресите на ПУ бяха листнати в няколко black list сървъра по моя вина. Администратор на мрежата на ПУ по онова време се оказа Атанас Терзийски с когото не се познавах. И вместо да ме постави на мястото ми той ми оказа максимално съдействие да отстраня проблемите и да конфигурирам правилно e-mail сървъра. Трябва да се отбележи, че още тогава ненавиждах linux-подобните ОС и работех само с Windows машини, но въпреки това Атанас ми съдейства без да има проблеми нито с вида на email сървъра, нито с ОС. Този email сървър работеше може би година (или две) и след това по естествен начин отпадна необходимостта от него. ПУ си имаше достатъчно стабилна пощенска услуга, която обезсмисли моите усилия да поддържам подобна такава.
Нека да пожелаем на сегашната пощенска услуга да обезсмисли алтернативната и то в скоро време. Докато обаче тя не се стабилизира хората не могат да бъдат лишени от алтернативи, тъй като правото на избор е неотменимо право.
Проблемът вече не е толкова в липсата на стабилност и функционалност защото има алтернатива. Проблемът е в това, че никой не поема отговорност. Фалът е чисто управленски и е достатъчно голям - както каза Светльо Енков 40 дни неизползваемост не са никак малко и хората мигрираха към употреба на акаунти в свободни сървъри. И това ако не е срам... А сега излиза едва ли не, че трябва да ръкопляскаме?!?
-
Тук, вече имам представа кой е с този ник :)
Не искам да коментирам излишно по темата, понеже нямам време да следя форума.
Богдане, това е един от проблемите, заради които мрънкаме. Един месец смятате, че коментарите по темата са излишни. Малко повече информация в подходящ момент и тази тема въобще нямаше да я има тук.
Искам само да споделя една снимка от телефона си - http://kovachev.info/uploads/2012-05-30%2011.06.26.jpg (http://kovachev.info/uploads/2012-05-30%2011.06.26.jpg). Ясно се вижда датата на която е направена, а това е стария пощенски сървър. Малко преди миграцията пощата започна да се държи странно и да се рестартира, да си маунтва партипъните с read права, като след repair на fs проблема продължаваше.
Според снимката тази машина разполага с 4 диска в RAID масив. До колкото аз знам дисковете бяха два по два в mirror. Изгърмял е един от дисковете. При такава ситуация обикновено се подменя изгърмелия диск с нов и загуба на информация няма. Подобен проблем имаше 2010 г. и нито един потребител не разбра за него. Принципно това е идеята на RAID контролера. Освен това датата на снимката е от 30.05.2012 г., а миграцията приключи на 27.05.2012!?
Така, че това едва ли може да е сериозен мотив за прибързаната миграция. Никой не отрича, че пощата имаше нужда от сериозни промени. Отрича се начина по-който все още се правят.
Можеха да ви дадат повече време за тази операция и да не се стига въобще до такава ситуация. Тъй като не става въпрос за 10тина потребители, а за стотици беше редно да се инвестира в нов диск, който да замени стария ($80 максимум), да направите сериозни тестове и да се запознаете подробно с избраният e-mail сървър - да му настроите правилно спам защитите, да качите всички фиксове налични до момента, да закупите нужният trusted сертификат и т.н. Обявявате 2 седмици по-рано, че ще има миграция и всичко освен inbox-a да се спаси и получавате 50% по-малко недоволни потребители. В предишен пост Наско обясни някой идеи за прозрачната миграция, които щяха да ви докарат още едно сериозно намаление на недоволните.
Защото в момента всички потребители имат усещането, че се направи сериозен downgrade на качеството на услугата, което е на път да обезсмисли големите усилия, които сте положили всъщност за подобряване. Малко по-спокойно ако се работи резултатите ще си заслужават усилията. Ако пък се възползвате и от услугите, които ви се предложиха не един път тук сигурно нещата ще се получат по-бързо и по-качествено.
-
Обявявате 2 седмици по-рано, че ще има миграция
Много точно казано! Щеше да се избегне хаоса с елементи на апокалипсис и скубане на коси :-X
-
На снимката с изгърмелият диск от RAID масива пише Call your support desk... На кого се обадихте, Богдане? И защо снимката е от 30.05.2012, нали уж проблемът е бил назрял, заради него сте обсъждали и решили да мигрирате? Защо на 30.05. все още не е оправен, нали все пак старият сървер седи за бекъп и за архив на писмата? Ох, забравих - с reset/ignore се оправя. И как може грешка в BIOS (хардуерна) да е основание за смяна на софтуера? Поне да беше Kernel panic от Линукса?
Точно преди 2 години при подобен проблем наистина сменихме пак диск от този масив. Никой не разбра за това, както каза Емил Дойчев. Е, Наско си дойде от морето, развали си отпуската, имаше малко бебе... Подробности. Купиха нов диск, смениха изгорелият, синхронизираха през BIOS и тръгна. Това точно е идеята на RAID.
Проумейте, че от 25.02.2012 лицето гл.ас. д-р по Химия Атанас Танов Терзийски НЕ ОТГОВАРЯ ЗА УСЛУГАТА! Вие подписахте приемо-предавателен протокол и получихте машината. Нямам и информация да сте комуникирали с него за съвети и съдействие? Ако ви ги е отказал - кажете го... Това променя нещата (той беше в Германия, но беше постоянно онлайн).
Пак ви се казва - приемете помощ, съвети и да действаме! Кой когато може, ще помогне.
Ако не - не се засягайте, просто изразих лично мнение. На GMail всичко е в ред, засега...
-
Тъй като опитите ми за комуникация с текущата ИТ-поддръжка на уни се оказват твърде неуспешни, искам да поставя един въпрос тук. А именно - някой успял ли е да настрои тъндърбърд, така че да може да ползва смтп услугата на новия сървър?
Относно цялостната ситуация, виждам че доста е изписано и не съм единствения с неполучени важни писма. Мога само да кажа, че капката която прелива чашата за мен е пълното нежелание на админите да признаят грешките и неуспехите си. Едно официално отправено предупреждение за ненадежността на услугата щеше да спести много нерви и проблеми на всички. По всичко изглежда, че надеждността все още е под въпрос, а официално изявление и предупреждение за потребителите продължава да няма. Нещо повече, администраторът спря да отговаря и на въпроси съвсем културно отправени по е-мейл. Макар че то вече не е съвсем сигурно и дали той самия си получава пощата при това състояние на услугата ...
-
някой успял ли е да настрои тъндърбърд, така че да може да ползва смтп услугата на новия сървър?
Няма да съм полезен, но все пак да споделя. Днес след преинсталация на Outlook успях да настроя без проблеми връзка с mail.uni-plovdiv.bg по IMAP. Бях решил, че ще ползвам само web клиента, но снощи той гърмеше така, че явно и на него не може да се разчита.
Thunderbird не съм ползвал никога, но след като IMAP с Outlook работи предполагам, че и с другите клиенти няма да има проблеми.
-
ИМАП работи, но по него доколкото знам мога само да дърпам налична поща, а не да изпращам. Поправи ме ако греша.
Ако е прекалено голям каприз да се ползва тъндърбърд, то поне да кажат.
-
И аз не съм с тъндърбърд. Ползвам Mail на MacOS X (на друг компютър с Windows съм настройвал аналогично Outlook Express). Настройките са ми: Сървър: mail.uni-plovdiv.bg; Портове: 25, 465, 587 (моя клиент пробва всички, но ако не може да задаваш повече от един порт, просто си поиграй и виж на кой ще захапе); Дал съм да се ползва SSL; Authentication разбира се си даваш името и паролата, като при мен е зададено да я праща като чист текст (по SSL не би трябвало да е проблем), но ти може да пробваш и други варианти, ако клиента ти го позволява.
Почти винаги праща :-) т.е. като работи сървъра. Само веднъж нещо писмото дето пращах се замота и ми се върна с "Delivery is delayed to these recipients or groups:......".
PS. В момента пощата пак не работи. Пробвам също да влезна през WEB клиента, но след Login формата излиза "обнадеждаващия" надпис: "Изглежда пощенската ви кутия не е налична. Опитайте да влезете пак след 10 секунди. Ако пак видите тази грешка, свържете се с помощния център.". Както и да е аз не се спичам от това щото и преди ми го е правил поне 4-5 пъти това новия сървър, така че "С упорство към прогрес" :wink:
-
Има и един железен workaround, който ще сработи - пращай си пощата през друг smtp сървър, напр. gmail. Докато spf е счупено няма никакво значение от чие име се подава пощата, след като не е от легитимните, описани в spf.
-
Красота и кеф:
Изглежда пощенската ви кутия не е налична. Опитайте да влезете пак след 10 секунди. Ако пак видите тази грешка, свържете се с помощния център.
Това от Web-базираната поща @ ПУ. Трети поп каза:
There was a problem logging onto your mail server. Your Password was rejected. Account: 'Enkov Uni', Server: 'poshta.uni-plovdiv.bg', Protocol: POP3, Server Response: '-ERR Server Unavailable. 21', Port: 995, Secure(SSL): Yes, Server Error: 0x800CCC90, Error Number: 0x800CCC92
За Тъндърбърд - Наско, виж си лога с мене, бях ти пращал WorkAround за него, който открих с Гугъл. Имаше 2 стъпки - едната беше ровене в Advanced Config Editor на Тъндърбърд, а втората - познайте - настройка в конзолата на MS Exchange Server. Уж с някакъв хотфикс за Exchange се оправяло, но дали този хотфикс е в импортант, за да се качи сам?... Не е ясно.
Помощният център го знаем вече, ще ни приложи снимка на изгорял RAID диск от старата поща. (шегувам се)
-
ИМАП работи, но по него доколкото знам мога само да дърпам налична поща, а не да изпращам. Поправи ме ако греша.
Не, не грешиш. IMAP и POP3 са протоколи за четене на електронна поща. Независимо от тях изпращането става с SMTP и всъщност сега проумях въпросът ти. Малко странно ми се струва да има проблеми с SMTP... все пак алтернатива няма.
Ако е прекалено голям каприз да се ползва тъндърбърд, то поне да кажат.
Е сега... малко търпение. Сигурен съм, че ще получиш отговор. Response Latency (http://psychology.wikia.com/wiki/Response_latency) на "Помощния център" (който и да е той) е между 10 и 40 дни.
-
http://uni-plovdiv.bg/news/index/88/
Начало » Новини » Прекъсване на Поща@ПУ
Прекъсване на Поща@ПУ
Временното прекъсване на услугата Поща@ПУ на 11.07.2012 г. от 08:45 ч. до 09:35 ч. се дължеше на ъпдейт на сървърите.
Последна промяна на 11 Юли 2012 г.
Уауууу, брейййй - случи се невъзможното. Взеха да уведомяват... Засега със задна дата малко, ама то така се почва, полека-лека.
Сега една секцийка Мрежови новини да направят - после редмайн или прожект... Ех, мечтиии...
-
Важното е, че все пак има някакъв ефект от цялото ни мърморене. :y:
-
http://uni-plovdiv.bg/news/index/89/
45 дена. Включва и пощата. "Бяхте предупреден!"...
Е, има напредък в уведомяването.
-
От едно известно време получавам доста често такива писма
Microsoft Forefront Protection for Exchange Server has detected a virus.
Virus name: "W32/Trojan3.DWI"
File name: "Fedex_IPI.zip->Fedex_IPO88832522.exe"
State: "Removed"
Subject line: "Your Package US7819528"
Sender: "FedEx"
Scan job: "Scheduled"
Location: "PU/Exchange Administrative Group (FYDIBOHF23SPDLT)/MAIL (Scheduled Scan Job\Атанас Т. Терзийски\Recoverable Items\Deletions)"
.
... което не ми говори много, освен че е някакъв вирус. Дали получавам вируси и има антивирусна на сървъра или е нещо друго? Ето писмото с хедъра:
X-Account-Key: account6
X-UIDL: 1549
X-Mozilla-Keys:
Received: from Pickup by mail.uni-plovdiv.lcl with Microsoft SMTP Server id
14.0.722.0; Thu, 26 Jul 2012 01:02:14 +0000
X-Sender: ForefrontServerProtection@MAIL.server
X-Receiver: atanas@uni-plovdiv.bg
From: <ForefrontServerProtection@MAIL.server>
To: <atanas@uni-plovdiv.bg>
Date: Thu, 26 Jul 2012 04:02:14 +0300
Subject: =?utf-7?Q?Microsoft Forefront Protection for Exchange Server detected a
virus?=
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
Message-ID: <713442b1-dab0-4c4e-a1e4-69a6e6656583@MAIL.uni-plovdiv.lcl>
Return-Path: ForefrontServerProtection@MAIL.server
X-MS-Exchange-Organization-AuthSource: mail.uni-plovdiv.lcl
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0
MIME-Version: 1.0
Microsoft Forefront Protection for Exchange Server has detected a virus.
=20
Virus name: +ACI-W32/Trojan3.DWI+ACI-
File name: +ACI-Fedex+AF8-IPI.zip-+AD4-Fedex+AF8-IPO88832522.exe+ACI-
State: +ACI-Removed+ACI-
Subject line: +ACI-Your Package US7819528+ACI-
Sender: +ACI-FedEx+ACI-
Scan job: +ACI-Scheduled+ACI-
Location: +ACI-PU/Exchange Administrative Group (FYDIBOHF23SPDLT)/MAIL=
(Scheduled Scan Job+AFwEEARCBDAEPQQwBEE- +BCI-. +BCIENQRABDcEOAQ5BEEEOgQ4=
AFw-Recoverable Items+AFw-Deletions)+ACI-
.
-
Ако самото "Fedex_IPI.zip" файлче не е атачирано към е-майла, значи наистина си е от антивирусната на сървера. Тези уведомявания могат да се регулират от настройките на Forefront for Exchange - дай предложение на екипа в УИЦ да ги изключи, но тогава може да пропуснеш реално писмо (с вирус де), за което поне би бил уведомен, че е спряно и не си го получил.
-
Ето две теми от зората на въпросния меил сървър "Topic: mail server (https://forum.uni-plovdiv.net/html/archives/20050420-11-000011.html)" и две години по-късно "Topic: mail.pu.acad.bg (https://forum.uni-plovdiv.net/html/archives/20050420-11-000021.html)"... и още две от зората на мрежата "Topic: LAN abuse !!! (https://forum.uni-plovdiv.net/html/archives/20050420-11-000008.html)" и "Topic: proxy (https://forum.uni-plovdiv.net/html/archives/20050420-11-000006.html)", също веселяшки.
-
Нищо ново под слънцето, това е ясно...
Поне се научихме да пишем на кирилица вече!
За емайл сървера, аз продължавам да си го ползвам предимно през GMail. Работи си перфектно, дърпа си ги през 15 минути и самият GMail си ме известява с Push и толкоз. И ако има проблем, дори не го усещам, просто няма нови мейли. Не ми дава грешка. Няма и спамец (има, ама си отива в СПАМ папката на GMail). E, като отговоря на писмо - е през GMail и последващата кореспонденция си е през него.
-
$ dig uni-plovdiv.bg mx
; <<>> DiG 9.8.3-P1 <<>> uni-plovdiv.bg mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31380
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;uni-plovdiv.bg. IN MX
;; AUTHORITY SECTION:
uni-plovdiv.bg. 1755 IN SOA dc.uni-plovdiv.lcl. hostmaster.uni-plovdiv.lcl. 208 900 600 86400 3600
;; Query time: 60 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 25 21:14:06 2012
;; MSG SIZE rcvd: 97
$ nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> set type=mx
> uni-plovdiv.bg
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
*** Can't find uni-plovdiv.bg: No answer
Authoritative answers can be found from:
uni-plovdiv.bg
origin = dc.uni-plovdiv.lcl
mail addr = hostmaster.uni-plovdiv.lcl
serial = 208
refresh = 900
retry = 600
expire = 86400
minimum = 3600
>
http://www.intodns.com/uni-plovdiv.bg
По всичко личи, че няма MX запис за uni-plovdiv.bg. В момента и до момента на корегиране на това няма входяща поща за домейна uni-plovdiv.bg
-
Сагата с тото лотарията продължава, от вчера имам върнати пощи към ПУ, сега пратих и не става нищо, хората не получават ... при вас как е
Technical details of temporary failure:
The recipient server did not accept our requests to connect.
[(0) uni-plovdiv.bg. [194.141.96.205]:25: Connection refused]
-
Остана ли някой, който да разчита на тази поща?
Вече повече от 24 часа сървъра е неоткриваем. Дали не е време вече някой от администраторите да се захване се нещо, което му приляга по-добре? Примерно отглеждане на картофи.
Това не са 1 или 2 часа. Тези ситуации показват, че никой от ръководството на този университет не ползва тази електронна поща (или поне не ежедневно). Иначе не мога да си обясня нищоправенето. По едно време имаше някакви наченки на информиране за проблемите около електронната поща, но сега 24 часа не се намери някой, който да публикува разяснително съобщение.
-
Днес тотално не става :)
(http://i518.photobucket.com/albums/u341/vebaev/ScreenShot2012-10-27at122049PM.png)
-
И аз не пиша често във форума, но го чета редовно.
Искам да попитам (изразя учудване) защо мрежата на ПУ, мейл сървъра и другите "ИТ" услуги, не се поддържат от хора на ФМИ.
Използвайки аналогии: при това положение колегите от ФМИ трябва да започнат да пишат стихотворение/хим. формули. Тогава бихте ли им се сърдили, че стихотворенията/формулите не са добри и не работят? -Едва ли. Мисля, че критиката е малко в повече.
Тук според мен има сериозна грешка допусната от ръководството - да се поверят услуги на хора с недостатъчна квалификация/опит/подготовка от други факултети, чиито дори образователна квалификация не е в това направление.
По мое мнение администрацията/координация на "ИТ" услугите трябва да премине под ръководството на ФМИ и звеното, което управлява г-н Чаушев.
-
Критиката не е повече. Щом някой е взел нещо и си е мислил, че може да го поддържа както требва - тогава да го направи! Ако не, да го даде на който трябва.
Мен като потребител не ме интересува кой ще го поддържа - ФМИ ЦМИ ММИ ДДИ ....... Важното е да работи стабилно, а това както се вижда не е така!
-
$ dig uni-plovdiv.bg mx
; <<>> DiG 9.6.-ESV-R5-P1 <<>> uni-plovdiv.bg mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41587
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;uni-plovdiv.bg. IN MX
;; ANSWER SECTION:
uni-plovdiv.bg. 3600 IN MX 10 poshta.uni-plovdiv.bg.
;; AUTHORITY SECTION:
uni-plovdiv.bg. 77117 IN NS dc.uni-plovdiv.bg.
uni-plovdiv.bg. 77117 IN NS rdoc.uni-plovdiv.bg.
;; Query time: 1 msec
;; SERVER: 194.141.99.99#53(194.141.99.99)
;; WHEN: Sat Oct 27 17:37:24 2012
;; MSG SIZE rcvd: 91
MX записа се появи, значи се работи по въпроса. Това, че сървъра е недостъпен в момента е бял кахър (засега) и ако тръгне (http://netmon.uni-plovdiv.bg/smokeping.fcgi?target=http.poshta_SMTP) до ден-два няма да има загубена поща.
-
@Beginner, старо ти е инфото - от 25 февруари 2012 година услугите се поддържат изцяло от Екипа на УИЦ в Ректората и нямат нищо общо с Атанас Терзийски и Химическият факултет. Колегите от УИЦ са подбрани с конкурс и са завършили задължително Информатика (не непременно във ФМИ на ПУ, но голяма част са си и кадри на ФМИ@ПУ). Така че, не е до стихотворения и химични формули. Нека не се приема като сарказъм - просто уточнение за съфорумеца Beginner.
Сърверите са нови, рутерите са нови, подходът е нов - е, нужно е още търпение, изглежда.
ПП - Мейл пратен в 19:26 го получих в 03:40 - много навреме. Днес хич няма - по указаните от Атанас причини, че нямаше MX запис (работи се по въпроса - виждаме). Пак добре, че е събота поне.
ПП2 - Не е нужно да се поемат услугите от админите на ФМИ, а да има сътрудничество, което нещо напоследък се наруши, по мое впечатление.
ПП3 - RSS на сайта на ПУ не работи от 14-15 дни, казах на уебмейстъра, обеща да го оправи - знаел кво е. Е, не е все още. Здраве да е. И това отписах...
ПП4 - Мейл @ Uni-plovdiv.bg ми се налага вече единствено, когато поръчвам части за тестване (evaluation) от Texas Instruments - не пращат, ако дам емайл в публичен сървер - казват за домашно ползване си платете или ползвайте друг канал за тестови части.
-
Пак добре, че е събота поне.
То стана неделя...а иди понеделник :bravo: Не че през почивните дни кореспонденцията е по-маловажна де :drunk:
Имам върнат майл на 26 на обяд казващ че ще се опита да ресендне още 2 дена, демек до днес на обяд след това адиос.....
-
Бегинър, доста иронично е, че мрежата и мейла в частност си работеше прекрасно докато беше под грижата на "хора с недостатъчна квалификация/опит/подготовка от други факултети, чиито дори образователна квалификация не е в това направление". Откак мина в ръцете на професионалисти вече е друга работа ... служебния мейл стана неизползваем и минахме на гмейл. Поздравления на айти съпорта! Така се гради престиж на университета.
-
@Енков: мерси за инфото, само че УИЦ е далеч по мое мнение от нивото на хората на г-н Чаушев и го доказват постоянно.
@Литий: за някоя дефиниция на "работи" и "прекрасно"...
Пак повтарям - това е проблем на организация, всичко друго е просто последствие.
-
Ако беше разчитал на служебен мейл в ПУ през последните 6 месеца и ако можеше да направиш сравнение с предходните години, то едва ли щеше да искаш дефиниция за "работи" и "прекрасно".
Какво точно не ти е ясно в определенията "работи" и "не работи"? Това дни наред да няма мейл, системно да се губят и да не се получават писма никога не го е имало!
-
http://uni-plovdiv.bg/news/news/118/
Кратко и лаконично! Ще има прекъсвания... А RSS ми дава все още http://uni-plovdiv.bg/news/index/118/ което е 404, вместо горният линк. Е, моля Ви се...
@Beginner - екипът на ФМИ са ми колеги, приятели и бивши студенти и дипломанти, респект пред тях, но все още няма поща@ФМИ, няма профили@ФМИ, няма Алумни, няма personal pages и блогове, фотосподеляне, мениджмънт на проекти, кво още няма... A Химикът ги беше направил всички тия неща @ПУ или @ХФ (работеха си добре, не перфектно). Не говоря за УИЦ, тук нямам коментар (тези дни... ще има прекъсвания). Да, Екипът на ФМИ има опита и знанията да ги направи, но... ги няма... Причините и аз ги знам, споко! Но ги няма...
Пак да уточня - критикувам в момента конкретно несправянето на УИЦ с последните нови проблеми с електронната поща - в УИЦ си има кадърни хора, но просто явно пощата (а и сайтът) не са им присърце, нямам друго обяснение. Всички забелязани от мен и от вас проблеми.с пощата, се оправят с 2-3 дни сериозно четене и тестване. Много се извинявам, но думата technical support има едно значение - да вървят и работят нещата. Да, аз сега ако се курдисам в УИЦ и седна да го оправям сам - ще ми отнеме може би повече време (най-вече защото не знам организацията и схемата на мрежата и настройките). Нека се стегнат и оправят нещата, това им го пожелавам искрено. Не плюя по тях.
-
@Литий: още една ключова дума: спам/спам филтри...
@Енков: Да съгласен съм напълно. Но това зададено ли им е като работен план? Ръководството иска ли го? Поставили ли са им го като задача? Аз съм сигурен, че ако има документ, който да казва какви са годишните цели нееднозначно нещата ще са коренно различни. Именно затова те не искат да си "играят" с нещо без да са получили официална задача, защото този резултат е неизбежен. Насоките се дават от ръководството (затова се казва ръководство), а не някой било му интересно седнал, играл си и станало нещо. И после като не работи го плюят.
-
@Beginner - Разгледай сайта на ФМИ - http://fmi.uni-plovdiv.bg/index.jsp?id=1426&ln=1
Поставени са доста задачи, имат и те доста критики от колеги и студенти. Проблемите се решават, разбира се.
Аз просто казах, че доста услуги предишният админ (условно Химикът) ги беше въвел почти самоинициативно и работеха и се използваха (и все още работят, те на практика УИЦ поеха само мрежата и пощата). И сега ги поддържа безплатно тези, които си останаха към него. Това, че ти и аз не ги ползваме (аз ползвам малко Focus Hosting и този форум де), не значи че други хора не ги ползват усилено (Блоговете, Форума, Фокус, Фокус Хостинг, Students /Moodle/ и др.). Нищо лично и нищо конкретно не казвам - просто с мерак се пускат нещата, не с чакане на заповед отгоре. Напротив - със заповед отгоре стана НОВАТА ПОЩА. Резултатът - видим е. Е, днес поне пак има поща... И ми дойде едно мейлче от петък. М/у другото - пак ще повторя - MS Exchange дори ми е по-приятен от старата поща, но проблемите са дразнещи (а те могат и трябва да се изчистят).
-
Както и да е - всеки си има позиция.
За мен това е абсолютен алогизъм. Поддръжката на тези услуги и т.н *трябва* да бъде правена от Факултета по Математика и Информатика. Там би трябвало да са ресурсите, необходими за това.
Редакция: И под поддръжка имам предвид сериозни неща като миграция на данни, подмяна на една система с друга, а не въвеждане на новини/некролози и друг контент във уеб сайтовете :)
Иначе в този ред на мисли, както е тръгнало, предлагам админите във ФМИ да започнат да дават правни консултации или да преглеждат пациенти - щото може на някой да му се отдава някое подобно занимание.
-
Beginner, според мен бъркаш малко нещата. Това, че ФМИ обучава IT кадри не означава, че IT поддръжката на ПУ трябва да се прави от ФМИ. Просто защото това е факултет, и един от многото факултети на ПУ, чието основно предназначение е обучение, а не каквато и да била поддръжка. По твоята логика следва да се очаква, че трябва да се закрие счетоводния отдел на университета и тази дейност да се поеме от Факултета по икономически и социални науки защото той подготвя кадри с подходящо икономическо образование.
ПУ, като голяма организация си има отделни звена, които се занимават със специфичните, съпътстващи обучението, дейности - наука, счетоводство, IT и т.н. За тези звена се предполага, че се наемат специалисти с опит и вероятно с конкурс. И това е правилният подход. Ако има проблем с ресора на някое звено то проблема трябва да се търси в самото звено. Защото както се оказа вече 4 месеца (като гледам първият ми пост) с електронната поща на ПУ не се случва никакво стабилизиране. Мисля, че за 4 месеца все някак си трябваше да се усвои администрацията на MS Exchange и да се подобрят нещата, но явно очакванията са повече от възможностите.
-
Ами, ако ФИСН има счетоводен отдел, който е по-компетентен от този на ПУ - абсолютно.
А що се отнася до "основното предназначение е обучение" мисля, че от тук загазва доста сериозно висшето ни образование, оттук се губи връзката с индустрията, оттук се губи връзката с накратко "останалия свят". Но това са теми за други дискусии.
Иначе се радвам, че мейла е тръгнал и може да получавате съобщения от преди седмица! ;)
-
http://netmon.uni-plovdiv.bg/smokeping.fcgi?target=http.poshta_SMTP
Сагата продължава! Следим я като турска сапунка...
-
Аз минах още преди 7 години на gmail, в този ред на мисли следя темата точно защото ми е мъка като гоедам колегите пък и си Е като турска сапунка :bravo: ... в момента пак няма достъп до Фатмагюл ...следва продължение :hihi:
-
Хайде да поразсъждаваме над това:
Pinging poshta.uni-plovdiv.bg [10.100.23.34] with 32 bytes of data:
Reply from 194.12.244.212: Destination net unreachable.
Reply from 194.12.244.212: Destination net unreachable.
Reply from 194.12.244.212: Destination net unreachable.
Request timed out.
Ping statistics for 10.100.23.34:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
За тези, които не се ориентират бързо подсказката е IP адрес: 10.100.23.34
Използвана литература: http://en.wikipedia.org/wiki/Private_network
-
$ dig poshta.uni-plovdiv.bg a
; <<>> DiG 9.6-ESV-R4-P3 <<>> poshta.uni-plovdiv.bg a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24370
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;poshta.uni-plovdiv.bg. IN A
;; ANSWER SECTION:
poshta.uni-plovdiv.bg. 1200 IN A 10.100.23.34
;; Query time: 70 msec
;; SERVER: 212.39.90.42#53(212.39.90.42)
;; WHEN: Fri Nov 2 22:08:47 2012
;; MSG SIZE rcvd: 55
$ nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> poshta.uni-plovdiv.bg
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: poshta.uni-plovdiv.bg
Address: 10.100.23.34
> set type=mx
> uni-plovdiv.bg
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
uni-plovdiv.bg mail exchanger = 10 poshta.uni-plovdiv.bg.
Authoritative answers can be found from:
>
$ ping poshta.uni-plovdiv.bg
PING poshta.uni-plovdiv.bg (10.100.23.34): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
(http://web.uni-plovdiv.bg/ksx/photo/forum/intoDNS%20%20uni%20plovdiv.bg.png)
-
http://uni-plovdiv.bg/news/news/118/
Абе, бяхме предупредени, кво толкоз! Няма срок, не са казани и какви ще са прекъсванията. Какво тук значи някакъв си DNS?
Шегувам се, стореното е просто издънка! Друга дума няма. Такова нещо дори с драг-дроп да се направи неволно, пак няма извинение никой админ.
-
Е педупредени сме .....прекъсване, прекъсване, колко да е прекъсване има няма 10 денчета :bravo:
Енков това да не ти е уникска-конзола, тва си е double-click-certified-serious-stuff-administration 8-)
-
Отварям страницата на пощата, но при опит за логване ми връща информация, че потребителското ми име или паролата ми не са коректни. Ако съм сигурна, че не бъркам при въвеждането на потребителско име и паролата, какъв може да е проблемът?
-
Проблемът не е в твоя ТВ а просто, че пощата не работи от повече от 10 дена, а ако случайно работи то неведоми са пътищата на писмата ти 8-)
ПП
при мен пък страницата не се отваря изобщо :drunk:
-
Много ти благодаря за отговора!
При мен страницата отваря само с Opera, но едва днес и сега. Сутринта, както и предишните дни, не се отваряше с никой браузър.
-
от днес следобед почна да работи
> poshta.uni-plovdiv.bg
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: poshta.uni-plovdiv.bg
Addresses: 194.141.96.231, 10.100.23.34
-----------------------------------------
СУПЕР ИНТЕРЕСЕН ПОДХОД! Който не разбира какво се е получило, ще поясня: Когато има 2+ МХ записа, сърверите използват алтернативно всеки запис подред, с цел балансиране на натоварването. ОК, обаче... вторият запис си седи в частна мрежа. И става "тука има, тука нема".
За казуса на Марта - Опера обикновено ползва свой DNS и кеширащ/компресиращ сървер в Турбо режима си, затова с нея е тръгнало преди другите браузъри. Направете ipconfig /flushdns в команден промпт с админ права, за да се опресни DNS.
-
"Назад към природата" :-)
т.е. да се върнем назад към IP-то. Не ни трябват DNS-и. Да пишем директно IP-тата.
Какво имам предвид? Ами ако нямате контрол над DNS кеша по някаква причина или не знаете кой и къде по пътя до вас го е кеширал и кога ще се обнови, просто сложете IP-то на сървъра в мейл клиента си (ако не ползвате WEB клиента на пощата на ПУ) вместо mail.uni-plovdiv.bg или poshta.uni-plovdiv.bg и... честито "Имате поща" :-) Тъпо, но ефективно. Едва ли някой скоро ще смени IP-то на сървъра или ще оправи DNS-а да не създава проблеми, така че заобикалянето на използването на DNS не е голям проблем за сега.
PS: Следващ етап на този почин ще е да откажем (освен от DNS-а) и от e-mail-а и да пращаме писмата си с гълъб, за по-сигурно и безпроблемно.
-
Дори и да забием твърдо истинското външно IP на mail сървъра това би ни помогнало единствено да видим, че нямаме нови писма. Също и да изпратим някое писмо, за което да не очакваме отговор. Или по-точно наистина да хвърляме боб ще има или няма да има случайно промъкнало се входящо писъмце.
Абе не знам само ние ли, тук пишещите има-няма 7-8 човека, от целия университет забелязваме какво се случва с пощата в последните 11 дни? Не мога да си представя, че това положение се търпи от ръководството на университета. Предполагам, че са в пълно невидение за ситуацията. Вероятно официалната кореспонденция минава през abv.bg.
-
Сега вместо страницата за логване в пощата излиза Willkommen на над 20 езика. А аз наистина имам нужда да си проверя кореспонденцията. Задочните ми студенти знаят само тази моя поща и съответно могат да ме питат за задачи само чрез нея, ако не са в състояние да дойдат на консултации, защото работят. А изпитът им наближава... :s:
-
Вероятно официалната кореспонденция минава през abv.bg.
ти пък, всичко е още на добрата стара тетрадка :bravo:
-
Изводите които можем да направим от създалата се ситуация са, че или университетското ръководство не ползва електронна поща или ако ползва такава не намира нищо смущаващо в това, тя да е хоствана на безплатен сървър от сорта на абв, мейл.бг или гмейл. И двата сценария говорят много зле за нас като университет. Оставям без коментар това, че и за голяма част от преподавателите изглежда е все едно има ли или няма поща.
-
Незнам как работят въобще?! те кореспонденсия извън БГ нямат ли? или само в сградата на ПУ и за това и по телефон става :hihi:
Мен ако за 10ч ми спре мейла се чувствам все едно са ми спрели телефона или тока....
-
Имат си поща в ПУ и си я ползват. И аз съм учуден от биволското им търпение.
-
"и си я ползват" звучи много весело в случая
-
В смисъл, не са промотирали официално АБВ мейла си - иначе във ФМИ (например) секретарките имат файл с 'алтернативни мейли' и пишат до тях при нужда.
-
Щом ще се ползва абв, поне да бяха го направили с google apps for education и да си имат ПУ поща отзад с google, щеше да е 100000% по сигурно от това в момента....
-
Абе, тук идеята е добра, нека е MS Exchange, да си е наше. Куриоза е, че както гледам - нещата отиват къв срив на домейна uni-plovdiv.bg изцяло, в момента вторият DNS е 10.100.23.2 - не говоря за МХ запис, а за резервният DNS на uni-plovdiv.bg - ако скапят и първият, става весело - всичко @уни ще изчезне, докато не го оправят, не само мейла.
Аз бях против Атанас да промотира и използва uni-plovdiv.net - но явно е усетил полъха на промените и се е ориентирал правилно.
Все още искрено се надявам УИЦ да си върне престижа и доверието и да оправят нещата бързо и коректно. Самата поща напоследък беше Ок, дори отскоро заработи и пренасочването на писмата, т.е. самият MS Exchange го понастроиха горе-долу (и антиспама се пооправи). В момента проблемите са от неизвестно за мен като причина некадърно (сори, нямам друга дума) пипане по записите на DNS. Аз също бях админ на ПУ (1995-2000) и пипах по тия записи и винаги ме е било адски страх да не объркам нещо. Явно има нещо, което не знам - или нови рутери/сървери ("техническите причини" от съобщението), с които имат проблем с настройването им (макар че DNS е един текстов файл с утвърдените отпреди 25-30 години RFC1034 и RFC1035 - настолно четиво на всеки мрежов админ).
-
Аз бях против Атанас да промотира и използва uni-plovdiv.net - но явно е усетил полъха на промените и се е ориентирал правилно.
И аз не одобрявах, но mail server-a @uni-plovdiv.net не е паднал вече 4 месеца (http://netmon.uni-plovdiv.bg/smokeping.fcgi?displaymode=n;start=2012-06-20;end=2012-11-5;target=http.mail_SMTP). За същото време @uni-plovdiv.bg има епизодични проблясъци.
Все още искрено се надявам УИЦ да си върне престижа и доверието ...
Ха, ха, ха... шегаджия :wink: То ако можеше да си върнеш нещо което никога не си имал и аз бих искал да си върна едни 10 милиона евро.
... макар че DNS е един текстов файл с утвърдените отпреди 25-30 години RFC1034 и RFC1035 - настолно четиво на всеки мрежов админ.
Май е време да влезе админ в УИЦ, а?
-
Дори и да забием твърдо истинското външно IP на mail сървъра това би ни помогнало единствено да видим, че нямаме нови писма. Също и да изпратим някое писмо, за което да не очакваме отговор. Или по-точно наистина да хвърляме боб ще има или няма да има случайно промъкнало се входящо писъмце.
Така е за съжаление, но аз вече го избивам на майтап. На мен все пак ми свърши работа да видя 1-2 писма (минали по закона на "боба") и да изпратя едно писмо, за което не чаках отговор.
Но ситуацията с DNS-а е абсурдна. Ако опрем да си даваме мейла като user@194.141.96.231 ще влезем в новините :hihi:
-
Уеб-мейла се появи! Това хубаво, но защо не ме разпознава като потребител?
-
Уеб-мейла се появи! Това хубаво, но защо не ме разпознава като потребител?
Трябва да сложих "uni-plovdiv/" пред името си, например "uni-plovdiv/atanas". Така става, аз пробвах.
-
Интересно, че става и ако в адреса заменя "bg" с "lcl" . Това става само от вътрешната мрежа де.
-
06 ноември 2012, 21:32 Извлечени бяха 200 имейла. Остават 1459 имейла.
06 ноември 2012, 21:28 Извлечени бяха 200 имейла. Остават 1659 имейла.
06 ноември 2012, 21:24 Грешка във връзката.
Сървърът даде грешка "Private IP address"
Тука има, тука нема, алтерира си МХ записите... КРАСОТА!
-
Логото на "новата ПУ поща" - "Добре дошли в света на бета-тестерите" :hihi: :bravo:
-
Свидетели сме на брутално съсипване на една услуга (според някои съботаж), която към началото на тази година достигна много високо доверие у потребителите. Към момента вече едва ли някой с активна кореспонденция разчита на тази поща. Основни отговорни за това мога да посоча Ректора и заместника му по IT (http://uni-plovdiv.bg/pages/index/14/). Ако някой се съмнява в това твърдение, бих го запитал "а каква се очаква да е ролята им изобщо като управленци". Техническата поддржка (http://uni-plovdiv.bg/pages/index/51/) няма нужда да се коментира, видимо е че липсва познание по материята мрежи и интернет, както и как се използват конкретните инструменти. Ако и да е така, момчетата работят под силен стрес на принципа "гасене на пожари", където е ясно, че нищо градивно не може да се случи.
Не пиша това с омраза или огорчение, дори напротив. Още веднъж публично декларирам, че за мен ще е приятно да помогна с каквото зная и умея - know-how, което основно придобих в ПУ за периода 1999-2012.
Удивително непонятно е за мен, как един такъв абсурд ни връхлетя в 21-ви век под един покрив където се говори за е-ПУ, стратегия ПУ-2020 (http://uni-plovdiv.bg/news/news/23), качество на обучение, фукане за престиж и прочие. Това за мен е дълбоко аморално поведение.
-
За съжаление тази дискусия се чете от една шепа хора, сред които едва ли влизат отговорните за ситуацията. Интересно дали процедурата по акредитация, която върви в момента, изисква електронна кореспонденция и каква точно поща ползват за целта архитектите на е-ПУ ;)
-
Според мен, дискусията си се чете и обсъжда, но никой не се решава да публикува, това е проблема. А всички страдат от проблема, очевидно е!
-
Абсолютен срам.
Пощенската услуга е може би най-старата електронна услуга, която се предоставя по принцип. С нея ПУ не може да се справи, а се говори за фантасмагории като Пловдивски електронен университет. Като спре да ме е срам пред студентите ще започна да се смея.
Не съм в позиция, а и не възнамерявам да оборвам критиките, засягащи теми от вида на „срам“, „позор“, „загуба на доверие“ и т.н., защото това не е конструктивна, а деструктивна критика.
Прав е бил гефикс, че сме деструктивни с нашата критика. Ето 4 месеца по-късно положението не е мръднало.
Удивително непонятно е за мен, как един такъв абсурд ни връхлетя в 21-ви век под един покрив където се говори за е-ПУ, стратегия ПУ-2020 (http://uni-plovdiv.bg/news/news/23), качество на обучение, фукане за престиж и прочие.
Колеги потребители на нефункциониращата поща на ПУ, моля ви да се стегнем малко и да започнем с конструктивни крититки, защото ако колегите от УИЦ я карат така още 4 месеца ще назначат на щат пощальон, а MS Exchange ще се чуди къде му е мрежовия кабел.
-
Техническата поддржка (http://uni-plovdiv.bg/pages/index/51/)
Удивително е колко много хора имало в УИЦ. Аз все като ида виждам 1-2ма. Но като гледам как работят нищо чудно като събереш всичките 12-13 човека да направиш 1-2 :) А най-удивително е с какъв непукизъм бездействат...
С риск да се потретя: въпрос на огранизация: Ако бях аз досега щях да се примоля или на Сашо или на Енков и щяха да го оправят за ден-два. Пак казвам това не е работа, която могат да вършат тиквите от УИЦ - те могат да проверяват дали си осигурен и т.н., мейл сървъри, администрация и организация е космоса (от магарето и космоса...)
-
Beginner, от висотата на твоята позиция нещата могат и да изглеждат по друг начин, но ако се поразровиш в тази тема ще видиш, че ние по-простите хора не си позволяваме да обиждаме колеги.
Бъди така добър да се контролираш. Ако няма къде да се правиш на велик - и тук не е подходящото място. Особено пък анонимен.
-
Ето - днес ми се обади моят ръководител катедра, 5 мейла се върнали и звъни на всички 1 по 1 по GSM - ще изпуснем срока да си попълним индивидуалните планове и заявките за избираеми дисциплини за втория триместър. Това е то, както казваше Кърт Вонегът...
-
Beginner, от висотата на твоята позиция нещата могат и да изглеждат по друг начин, но ако се поразровиш в тази тема ще видиш, че ние по-простите хора не си позволяваме да обиждаме колеги.
Бъди така добър да се контролираш. Ако няма къде да се правиш на велик - и тук не е подходящото място. Особено пък анонимен.
Не знаех, че съм анонимен, а също не знаех че това е критерии, по който се съди и трябва да се съди.
Уважавам твоята колегиалност - прав си "по принцип" не трябва да обиждаме колеги. Моята обида (ако изобщо може да се нарече така) се отнася не до тях лично, а до тях професионално. Когато човек си върши добре работата получава съответните определения, когато не - също.
Изразявам личното си мнение (както всички тук) и ако обичаш не се опитвай да ми казваш как да го правя. Обърни се към модератор, ако смяташ, че нещо не е както трябва.
И да говоря от позицията на човек, администриращ cloud инфраструктура + мейл сървър (няколко) + какво ли още не. Надявам да не съм ти вече много анонимен. Сега мнението по-висока стойност ли има? Мога да дам и ЕГН, адрес, месторабота, CV, хобита, ако е необходимо. Само кажете, че това ще оправи проблемите :)
-
На фона на е-пощата се насладете на новината:
http://www.gustonews.bg/?page=article&instanceID=23113
смях....и то голям!
-
На фона на е-пощата се насладете на новината:
http://www.gustonews.bg/?page=article&instanceID=23113
смях....и то голям!
Веско, не виждам кое ти е смешно? Виж по-добре тази новина:
Софийски университет "Св. Климент Охридски" спечели пет проекта в различни факултети и департаменти на обща стойност над 3 млн. лева, а Техническият университет в София - два проекта за общо 814 240 лева. Останалите вузове участват с по един проект...
3 милиона за СУ срещу 0.76 милиона за ПУ. Знаеш ли защо е така? Защото ръководството на ПУ (http://uni-plovdiv.bg/pages/index/14/) реши, че цялото ПУ ще представи един "голям" проект, като се забрани на факултетите да пускат свои проекти - резултата цифром е видим и е близо 4 пъти по-малко средства от СУ.
Не ми се иска да разводняваме темата с това, така че ако искаш отвори си отделна тема!
Относно "Re:Електронна поща в ПУ" на всички тук предлагам следното: Искате ли със разбиранията, които имаме да постваме съвети, които биха оптимизирали работата на тази поща. Дори и да не се вземат в предвид, ще е едно добро и позитивно упражнение за нас... настрана че случая е наистина интересен. т.е. нещо като обратно инжинерство, хихи. Аз ще подготвя своя пост скоро.
Edit, ref. към цитата отгоре: http://www.dnevnik.bg/bulgaria/2012/11/07/1941543_13_visshi_uchilishta_shte_razvivat_sistemi_za/
-
Е как какво общо има? Една поща не можем да направим, цялата Мара втасала, а е-обучение ще месим.....
-
$ dig uni-plovdiv.bg mx | grep -v ^";"
uni-plovdiv.bg. 2949 IN MX 10 poshta.uni-plovdiv.bg.
uni-plovdiv.bg. 2949 IN MX 11 mail.uni-plovdiv.bg.
Това казва, че има два оторизирани сървъра, които могат да приемат поща за домейна UNI-PLOVDIV.BG. В случая обаче, както се вижда по-долу, това е една и съща машина и примерно втория запис може да се изтрие. При всички положения обаче е добре, да не кажа задължително да се договори още една машина някъде, която да пази пощата, която тази с по-висок приоритет отсъства.
$ dig poshta.uni-plovdiv.bg a | grep -v ^";"
poshta.uni-plovdiv.bg. 510 IN A 10.100.23.34
poshta.uni-plovdiv.bg. 510 IN A 194.141.96.231
Записа 10.100.23.34 трябва да се махне на всяка цена. Това е частна мрежа (10/8), която няма място за публичен меил сървър.
$ dig mail.uni-plovdiv.bg a | grep -v ^";"
mail.uni-plovdiv.bg. 2884 IN A 194.141.96.231
Да, това е същия адрес и може изобщо да се махне от MX записите.
$ dig uni-plovdiv.bg txt | grep -v ^";"
uni-plovdiv.bg. 3266 IN TXT "v=spf1 mx a:mx.acad.bg -all"
Това е стар запис, когато mx.acad.bg беше вторичен на poshta.uni-plovdiv.bg. В момента това не е така и трябва записа да се корегира. Мисля, че "v=spf1 mx -all" е едно добро рестриктивно начало. За повече инфо виж тук: http://www.openspf.org/SPF_Record_Syntax
dig uni-plovdiv.bg soa | grep -v ^";"
uni-plovdiv.bg. 3600 IN SOA dc.uni-plovdiv.lcl. hostmaster.uni-plovdiv.lcl. 312 900 600 86400 3600
1) hostmaster.uni-plovdiv.lcl има смисъла на e-mail и може би е добре да се корегира с administrator.uni-plovdiv.bg;
2) dc.uni-plovdiv.lcl каквото и да значи не е публичне адрес и няма място тук;
3) TTL стойностите са много малки и това може излишно да товари DNS сървъра.
dig uni-plovdiv.bg ns | grep -v ^";"
uni-plovdiv.bg. 281307 IN NS rdoc.uni-plovdiv.bg.
uni-plovdiv.bg. 281307 IN NS dc.uni-plovdiv.bg.
Силно препоръчително е да има повече вторични сървъри. Такива могат да се договорят сред колеги, а има и доста публични, свободни и доста надеждни услуги.
Ако съм пропуснал нещо - помагайте...
-
Още един пач.
; <<>> DiG 9.6-ESV-R4-P3 <<>> poshta.uni-plovdiv.bg aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27728
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;poshta.uni-plovdiv.bg. IN AAAA
;; ANSWER SECTION:
poshta.uni-plovdiv.bg. 1200 IN AAAA 2001:4b58:27:23:4d4d:fcf3:7246:8f80
;; Query time: 9 msec
;; SERVER: 10.100.23.2#53(10.100.23.2)
;; WHEN: Fri Nov 9 15:24:21 2012
;; MSG SIZE rcvd: 67
Сега забелязах, че пощата има и IPv6 адрес, който обаче за съжаление не е достъпен от света. Това може да възпрепядства достъпа и получаването на поща от IPv6 enables хостове. Бива (1) или да се оправи маршрутизацията или (2) да се махне този адрес.
-
След като ми писна от 10.100... и ми се обади пак ръководителят на катедрата ми за проблем с доклада за избираемите дисциплини, които водя, ми писна и направих нещо, което не е нито правилното решение на проблема, нито ми се искаше: в \windows\system32\drivers\etc\hosts (за Windows XP) добавих запис 194.141.96.231 poshta.uni-plovdiv.bg
След проверка в DNS, установих, че все още:
poshta.uni-plovdiv.bg. 1200 IN A 10.100.23.34
poshta.uni-plovdiv.bg. 1200 IN A 194.141.96.231
Да, знам че записите са равноправни и се алтерират 50/50, но днес ми се закучи 10.10... в кеша и не помагаше и flushdns, та се наложи модифициране в hosts файла!
Срам и позор, повече не мога да защитавам УИЦ. Запис на локален адрес в DNS не е допустим по никакъв начин!
-
... Запис на локален адрес в DNS не е допустим по никакъв начин!
Ок, приемаме, че този локален адрес е влязъл в DNS-a случайно. Сега някой да обясни как се маха от там и може и да изчезне така както се е появил.
-
Днес се провали един електронен изпит на БИТ първи курс понеже се оказа, че писмата, които трябва да получат студентите след успешна регистрация във Фокус не се получиха. А тези писма съдържат активационен линк. Пак днес подобен проблем се получи и с 37 студента от филиала в Кърджали.
Оказа се, че невероятно сложният за поддръжка и настройка мейл сървър mail.uni-plovdiv.bg не изпраща писма. За да не се случват друг път такива изцепки Фокус вече използва алтернативния мейл сървър mail.uni-plovdiv.net.
Тук вината и отговорността я поемам лично аз. Трябваше да настроя Фокус да използва алтернативния мейл сървър преди 5 месеца. Сега поради моя неправилна преценка се провалиха неща, които нямат пряка връзка с електронната поща на ПУ.
Закачих си още една обица на ухото.
-
Оказа се, че невероятно сложният за поддръжка и настройка мейл сървър mail.uni-plovdiv.bg не изпраща писма. За да не се случват друг път такива изцепки Фокус вече използва алтернативния мейл сървър mail.uni-plovdiv.net.
Мда и аз имах подобни проблеми, и предвидливо пренасочвам мейловете за регистрации и други подобни през специално направен акаунт в GMail. Ама това може, но другото е по-сложно да заработи мейл сървъра, така че да не мислим за него, а просто да го ползваме. Вече се замислям за един прокси мейл сървър пред Exchange-то да форвардва писмата за хората, които искат към алтернативен мейл сървър (mail.uni-plovdiv.net, GMail или друг), а който не иска да отива във Exchange-a. И това проски да се направи един път и да не се пипа от никой и да не се мажат DNS настройките му. Ама това е само меееечтаааа :-)
ПС. Не ща да ми форвардва Exchange-а, защото той когато не работи какво правим (а той знаем по-често не работи).
-
Айде, честито!!! Май gmail-a ни блокираха IP адреса на poshta.uni-plovdiv.bg
Това можеше да се очаква, де, ама... дано да е временно, защото едва ли някой ще се трогне да ни изкара от black-list-a им :-)
Днес пратих четири писма и четирите се върнаха. Ето какво ми се върна за едно от тях. (Замазал съм личните данни конкретното съдържание на мейла със ****)
Microsoft Outlook <MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@uni-plovdiv.bg>
Subject: Undeliverable: Re: [Александър Пенев] Проект **********
Date: November 30, 2012 5:18:07 PM GMT+02:00
To: Александър Пенев <apenev@uni-plovdiv.bg>
-------------------------------------------------------------------------------
mx.google.com rejected your message to the following e-mail addresses:
s*****@gmail.com
mx.google.com gave this error:
[194.141.96.231 1] Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines. nm5si3593491lab.47
Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept e-mail from certain senders, or another restriction may be preventing delivery.
Diagnostic information for administrators:
Generating server: poshta.uni-plovdiv.bg
s******@gmail.com
mx.google.com #550-5.7.1 [194.141.96.231 1] Our system has detected an unusual rate of 550-5.7.1 unsolicited mail originating from your IP address. To protect our 550-5.7.1 users from spam, mail sent from your IP address has been blocked. 550-5.7.1 Please visit http://www.google.com/mail/help/bulk_mail.html to review 550 5.7.1 our Bulk Email Senders Guidelines. nm5si3593491lab.47 ##
Original message headers:
Received: from [10.0.5.110] (194.141.98.1) by poshta.uni-plovdiv.bg
(10.100.23.34) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 30 Nov
2012 09:22:58 +0200
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Apple Message framework v1085)
Subject: =?utf-8?B?UmU6IFv************************
From: Alexander Penev <apenev@uni-plovdiv.bg>
In-Reply-To: <E1TeK1c-0001BU-VJ@s8.r1servers.com>
Date: Fri, 30 Nov 2012 09:20:00 +0200
Content-Transfer-Encoding: base64
Message-ID: <6395ACCD-B3D9-4200-8239-D0BDB05C5DED@uni-plovdiv.bg>
References: <E1TeK1c-0001BU-VJ@s8.r1servers.com>
To: <s*****@gmail.com>
X-Mailer: Apple Mail (2.1085)
Return-Path: apenev@uni-plovdiv.bg
Reporting-MTA: dns;poshta.uni-plovdiv.bg
Received-From-MTA: dns;[10.0.5.110]
Arrival-Date: Fri, 30 Nov 2012 07:22:58 +0000
Final-Recipient: rfc822;s*****@gmail.com
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp;550-5.7.1 [194.141.96.231 1] Our system has detected an unusual rate of
550-5.7.1 unsolicited mail originating from your IP address. To protect our
550-5.7.1 users from spam, mail sent from your IP address has been blocked.
550-5.7.1 Please visit http://www.google.com/mail/help/bulk_mail.html to review
550 5.7.1 our Bulk Email Senders Guidelines. nm5si3593491lab.47
Remote-MTA: dns;mx.google.com
From: Alexander Penev <apenev@uni-plovdiv.bg>
Date: November 30, 2012 9:20:00 AM GMT+02:00
To: <s******@gmail.com>
Subject: Re: [Александър Пенев] Проект ********
*******текста на оригиналното съобщение******
-
Хай,
Хм, gmail вероятно имат някаква по-интелигентна защита (не просто RBL (http://en.wikipedia.org/wiki/DNSBL)). Преди няколко дена си пуснах писмо до gmail и едва сега го изрових в trash папката. Иначе ето какво откривам тук (http://www.projecthoneypot.org/ip_194.141.96.231):
From: C.Y Lin <gdam@uni-plovdiv.bg>
Subject: Re:
From: Alex Gregorwicz <gdam@uni-plovdiv.bg>
Subject: Re: Tr
Явно наистина е излизал яко спам от ПУ и това е причината да сме в няколко RBL бази. Може би следваща задача ще е ваденето на IP-адреса на пощата от тях. Разбира се трябва да се вземат и всички препоръки, казани до тук.
-
Скоро не бях се пробвал да пращам от служебния си акаунт, но днес се излъгах и ето какво последва:
(Умишлено съм скрил името на получателя)
aitana.cpd.ua.es rejected your message to the following e-mail addresses:
****** ********** (*****@ua.es)
aitana.cpd.ua.es gave this error:
Mail from 194.141.96.11 rejected using BRBL Block List. Please see http://www.barracudacentral.org/rbl/listing-methodology
А, и весели празници на всички! :)
-
The original message was received at Sat, 9 Feb 2013 22:30:51 +0200 (EET)
----- The following addresses had permanent fatal errors -----
<***@uni-plovdiv.bg>
(reason: 554 5.1.0 Sender denied)
----- Transcript of session follows -----
... while talking to poshta.uni-plovdiv.bg.:
>>> MAIL From:<> SIZE=5331
<<< 554 5.1.0 Sender denied
554 5.0.0 Service unavailable
По принцип получавам поща, а с тестване също изглеждат ОК нещата. Периодично обаче ми се случва да видя и такова съобщение във върнатите. :roll: Някой има ли подобни наблюдения?
-
Вече си мислих, че няма да получим разнообразие и няма да спре да работи някоя услуга на мейла.
Е, грешката е в мен :-)
От няколко дни няма IMAP/IMAPS достъп до мейл сървъра. Все пак не всеки държи да ползва POP3 протокола.
Разбира се това става както винаги точно когато има нещо важно. От няколко дни един от курсовете, които водя започват интензивно да ми предават проектите си (на майла) и аз точно сега не мога да си тегля пощата :-) Ама то това са студентски истории - не е важно :wink: Важното е спам да има :-)
-
Човек заобикаля липсващите услуги, пренстройва, ползва WEB интерфейса и ....
Кой ще се сети? Сървърите съвсем спряха (даже форума) и как човек да постне, че няма поща :-)
Вече няма да казвам нищо, щото явно съм ги урочасал :wink:
-
Мигрирай на mail @ uni-plovdiv.net. Там работи и IMAP... даже без прекъсвания.
-
И отново прекъсване от 1 седмица, само дето вече спря да ни прави впечатление ...
Тези хора явно искрено вярват, че през ваканциите поща не е необходима.
-
https://uni-plovdiv.bg/news/news/159/ (https://uni-plovdiv.bg/news/news/159/)
-
Server Error
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
Това преди даже да съм въвел юзърнейм/парола.
-
Security-то на този мейл сървър е стигнало небивали висини. Последно ми беше сменена паролата защото излизал спам от моя акаунт. И подхода към справяне с този проблем ме хвърли в дълбок размисъл в продължение на дни. Дори не помня дали успях да се свържа с някой за да ми сложи парола, която да знам и аз. Сега явно нещата са затегнати още - спира се достъпа до сървъра въобще. Интересно ако продължава да се разпространява спам с подател университетски акаунт каква ще е следващата стъпка :)
Щото май не останаха варианти. Дали пък не се работи в грешна посока?
-
Явно валидният адрес за достъп до web клиента на тази поща е станал само по HTTPS протокола. Т.е. https://mail.uni-plovdiv.bg (https://mail.uni-plovdiv.bg)
Едно елементарно пренасочване от http към https щеше много да е от полза.
-
Изрева вече доста народ, който си беше фаворитнал/букмаркнал адреса без https. Е, случват се такива неща в УИЦ, вече не ги критикувам дори. А по РОР3 е само без SSL... Преди имаше SSL/SPA. Ефекта същият за потребителите - пощата не ми работиииии... Вече гледам позитивно безразлично. Сори!