diffor

Нарвался на интересный случай - на сервере (Windows 2003 R2) несколько учёток админа. На одной из учёток не запускаются исполняемые файлы по сети с сетевых smb-шар ( \\server\apps\app.exe ), причём локально всё нормально ( D:\apps\app.exe ), причём на других учётках запускается и так и так. Группы одинаковы, права перепроверены на 10 рядов. На этой учётке выдаёт сообщение:
"Отказано в доступе к указанному устройству, пути или файлу. Возможно, у вас нет нужных прав доступа к этому объекту"
и это то у админа домена? хм...

Решилось весьма интересно - удалил компонент "Конфигурация усиленной безопасности Internet Explorer", всё заработало. Удаляется через Панель управления -> Установка-удаление программ -> Компоненты Windows

P.S. Судя по гуглу случай не еденичный и ситуация проявляется на рандомных учётках в зависимости от фазы луны.

SVN, как и другие системы контроля версий, очень удобен при разработке программ. Например, можно отследить все изменения и откатить не понравившиеся; отпадает проблема синхронизации и объединения изменеий при коллективной разработке или индивидуальной на нескольких машинах (например ноутбук и десктоп); и многое другое.

Сначала определимся с понятиями.
Серверная копия (репозиторий) - серверная база, хранящая историю изменений, между отправкамит на сервер (коммитами). Состояние исходников на определённый коммит, называется ревизией (версией).
Рабочая копия - клиентская копия, с метаинформацией для svn. В ней и правятся исходники и после правки, изменения отправляются (коммитятся) на сервер, создавая новую ревизию.

Собственно команды:

svn checkout - создать рабочую копию, получив текущую ревизию с сервера. Пример: http://svn.altlug.ru/p/www_nix-files/ - создастся директория с именем www_nix-files, содержащая рабочую копию.
svn update - обновить рабочую копию с сервера (получить изменения). Если в вашей рабочей копии и на сервере были изменения, произойдёт попытка их объеденить.
svn diff - посмотреть внесённые изменения в вашу рабочую копию.
svn commit - отправить изменения на сервер, при этом будет создана новая ревизия.

svn add - добавить файл в рабочую копию. При commit файл будет отправлен на сервер. Пример: svn add trunk/TODO
svn rm - удалить файл из рабочей копии. При commit файл будет удалён из текущей ревизии на сервере. Пример: svn rm trunk/TODO
svn mv - переместить файл внутри репозитория. Пример: svn mv trunk/test.cpp trunk/src/module.cpp
svn revert - откатить изменения в файле из рабочей копии. Пример: svn revert trunk/main.cpp

Это далеко не полный список команд, но для начала вполне достаточно.

Раньше использовал rdesktop для подключения по RDP к машинам с Windows. Только вот он некорректно работает с раскладками, имеет глюк с залипающим альтом, не умеет RDP v6 (Win 2008,7), буфер обмена частенько не жуёт, да и ещё глюки разные встречал...

И вот наткнулся на FreeRDP, который лишён этих недостатков. С версии 0.8 его начал использовать Remmina - графический клиент для удалённых рабочих столов на гтк, весьма удобный и умеющий ssh-тунелли.

В репозитории Ubuntu 10.04 лежит старая версия Remmina, которая ещё использует rdesktop, но есть PPA со свежей версией. Ставим:

sudo add-apt-repository ppa:llyzs/ppa
sudo apt-get update
sudo apt-get install remmina

И наслаждаемся =)

Поставить почтовый сервер и сделать MX-запись о нём в DNS недостаточно - любой вменяемый спамфильтр будет резать письма с него.
Почему?
1. Обратная зона
Согласно RFC у почтовиков должна быть корректно прописаная обратная зона, соответствующая записи в MX.
Обратная зона, отличается от прямой тем, что осуществляется преобразование не имени в IP, а обратно из IP в имя.
Классические ошибки:
- обратная зона не прописана вовсе
- обратная зона дэфолтная провайдерская (типа dsl-11-11.provider.ru)
- обратная зона отличается от записей в MX (например в MX - mail.firma.ru, а обратка отдаёт gate.firma.ru)
Лечится письмом в саппорт провайдера, с запросом о смене имени для нужного IP в обратной зоне.
2. HELO
Некорректное имя HELO в настройках почтовика - там должен быть домен. Проверить можно обычным телнетом на 25 порт.

Ссылки по теме:
http://www.ietf.org/rfc/rfc821.txt
http://www.ietf.org/rfc/rfc2821.txt

Зачем-то на свою голову восстановился... Даже сессию всю как-то лихо сдал, только вот...

С переходом с вэбстрёма (ADSL) на Интелеку (Ethernet), пришлось отправить на покой железный роутер Linksys WAG325N... И собственно встал вопрос о раздаче Интеренета по WiFi, сервер на атоме оказался как раз кстати.

Дано:
Хост: Atom-330 на Intel D945GCLF2
WiFi-карта: D-Link DWA-520 (внутри Atheros AR5001X+) с кстати оказавшейся в комплекте низкопрофильной планкой (иначе бы в корпус не впихнуть, разве что совсем без планки).
ОС: XUbuntu Linux 10.04

Делал по аналогии со статьёй http://habrahabr.ru/blogs/linux/67717/ с изменениями под себя.
Патчить и ставить из сторонних репов ничего не понадобилось - hostapd и ath5k штатные. Поднимается довольно быстро и работает стабильно (3 дня тестдрайва 13 дней тестдрайва нонстоп).

Дано: PostgreSQL 8.4.4 на Windows 2003 с часовым поясом Азия/Новосибирск.

После перехода на летнее время начал некорректно отрабатывать now(),localtimestamp и иже с ними - показывают на час меньше системного времени, причём в тойже Pg на Linux всё корректно...

В результате ковыряний обнаружилась интересная весч:
Запрос: show timezone
Ответ: Asia/Almaty
Хотя должно быть Asia/Novosibirsk... Как показал гугль, время в Алматы на летнее не переводится...

Лечение - в конфиг postgresql.conf добавляем строчку:
timezone = 'Asia/Novosibirsk'
(!) кавычки обязательны

Upd. Отправил багрепорт разработчикам, тикет №5466
Upd 2. Выяснил причину: December 2009 cumulative time zone update for Microsoft Windows operating systems
Upd 3. Написал патч =) Дифф для файла src/timezone/pgtz.c

892c892
<               "Asia/Almaty"
---
>               "Asia/Novosibirsk"

Upd 4. Патч приняли, в следующем релизе этой проблемы не будет.
Upd 5. Вышла версия 8.4.5 с исправлением.

Встретил http://ithappens.ru/story/2889 и что-то мне подсказывает, что в этой сети кроме DSL-2500U, появился ещё и реальный DSL-G804V (м.б. какому-то юзеру захотелось вафли, ну или как свитч его использовали...) - из этого получаем конфликт IP-адресов и попеременное появление по одному и тому-же адресу (чую что это 192.168.1.1) разных админок... А человек пытается решить проблему прошивкой... венда, что ж ты делаешь с людьми: появилась проблема - переставить, перешить...

Дано: Windows XP SP3 с последними обновлениями. Банк-клиен (и, как оказалоь, другие проги) с инсталлятором InstallShield (другие нормально пашут).

Получаем: Инсталлятор вроде-как запускается - в процессах висит setup.exe, но признаков жизни не подаёт. Если очень терпеливо подождать некоторое время, то таки появится инсталляторный диалог выбора языка - выбираем и... всё - ждать дальше бесполезно.

Пробуем: Пробовал удалять SP3, переставлять Windows Installer - безрезультатно... Однажды таки почти удалось завести инсталлер убив один из процессов svchost.exe o_O Правда система после этого запустила принудительный ребут через минуту... =( (P.S. Вирусов на машине нет 100%)

Решение: грузимся в безопасном режиме и внезапно в нём этот инсталлер начинает работать O_o Причём установка прошла корректно и до конца...

P.S. Пробовал на нескольких машинах.
P.P.S. На Windows 2003 Server таж фигня o_O
P.P.P.S. Причём я не одинок (например http://www.administrating.ru/problema-s-installshield-medlennaya-ustanovka-i-zavisanie-setup-exe/ и не только), прямого решения так и не нашёл, но хоть обойти можно - ищем дальше...

Дошли руки до шлифовки сервера... Звуковуха прекрасно работает из коробки в режиме 2.0 с микрофоном и линейным входом, но вот как переключить mic и line на выхлоп для 5.1 было загадкой, хотя по спекам она это умеет. Итак:

diffor@diffor-server:~$ lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

diffor@diffor-server:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]

Почему-то звуковуха упорно не хотела выдавать 5.1 и сильно ругалась даже на:
speaker-test -c 6 -D surround51 -t wav
К сожалению логов не сохранилось. После некоторого гугления и шаманства с ~/.asound.rc, которое никак не помогало, нашёл решение проблемы:

diffor@diffor-server:~$ cat /etc/modprobe.d/alsa-base.conf | grep snd-hda-intel
options snd-hda-intel power_save=10 power_save_controller=N model=3stack-6ch

В общем нужно было передать модулю ядра модель звуковухи (подчёркнуто) и в alsamixer'е появится переключатель между 2ch и 6ch. Переключаем через alsamixer store от рута, чтобы состояние восстанавливалось после запуска. Радуемся =)

З.Ы. Модель можно подобрать исходя из чипа тут:
http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio-Models.txt

Upd. В 10.04 такой строчки в конфиге не оказалось, нужно её просто добавить.