Нарвался на интересный случай - на сервере (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 порт.
С переходом с вэбстрёма (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... Как показал гугль, время в Алматы на летнее не переводится...
Встретил 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 Причём установка прошла корректно и до конца...
Дошли руки до шлифовки сервера... Звуковуха прекрасно работает из коробки в режиме 2.0 с микрофоном и линейным входом, но вот как переключить mic и line на выхлоп для 5.1 было загадкой, хотя по спекам она это умеет. Итак:
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, которое никак не помогало, нашёл решение проблемы:
В общем нужно было передать модулю ядра модель звуковухи (подчёркнуто) и в alsamixer'е появится переключатель между 2ch и 6ch. Переключаем через alsamixer store от рута, чтобы состояние восстанавливалось после запуска. Радуемся =)
