пятница, 26 июля 2013 г.

Блокировать экран по ALT+CTRL+L с использованием xscreensaver

Если вы установили screensaver, и вам необходимо блокировать экран, используя старую комбинацию ALT+CTRL+L, то вам необходимо:

1) Если вы не удалили старый gnome-screensaver, его нужно снести:

sudo apt-get remove gnome-screensaver

2) Теперь нужно создать символическую ссылку на старую команду, чтобы система посылала сигнал о блокировке экрана на xscreensaver:

sudo ln -s /usr/bin/xscreensaver-command /usr/bin/gnome-screensaver-command


Все, проверяем.

Перезагрузка gnome-shell из консоли

Случается (по крайней мере у меня на 19-й Федоре), когда gnome-shell падает, да с таким грохотом, что никакой atl+f2 не спасает. И что же делать? Перезапускать gdm3? Зачем, если можно всего-то сделать следующее:

1) Идем в консоль по atl+f1 / alt+f2 (каждому свое)
2) Пишем там команду w, чтобы узнать дисплей, с которого сидим:

clem@host:/$ w
 15:23:19 up 23:42,  5 users,  load average: 0.03, 0.11, 0.38
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
clem     tty1                      11:32    8:03  16.14s  0.01s /usr/lib/gnome-shell/gnome-shell-calendar-server
clem     pts/0    :1               11:13    4:07m  3.17s  9.61s gnome-terminal
clem     pts/1    :1               11:26    3:52m  2:17   0.27s bash
root     pts/2    :1               12:03   21:53   0.36s  0.36s /bin/bash -i
clem     pts/3    :1               14:56    0.00s  0.39s  0.00s w


В колонке ""FROM" наблюдаем наш дисплей, в данном случае - "1".

3) Прописываем следующую команду, заменяя мою "1" своим значением

clem@host:/$ export DISPLAY=:1.0

4) И напоследок вбиваем следующую команду:

clem@host:/$ gnome-shell --replace

5) По alt+f7 (или что там в вашем дистре) возвращаемся в графику и.... вуаля, все работает :)

понедельник, 22 июля 2013 г.

Установка Wine 1.6 в Fedora 19

Для установки вышедшей 20.07.2013 тестовой версии wine 1.6 нужно провернуть следующие операции:
 
yum upgrade
 
yum --enablerepo=updates-testing install wine
 
Это откроет возможность загрузки пакетов с тестовой ветки, и позволит установить последнюю находящуюся в репозитории версию пакета.

воскресенье, 21 июля 2013 г.

Установка Fedora 19 from USB-drive /dev/root does not exist

При установке Fedora 19 с флешки столкнулся со следующей проблемой, которая, похоже, существует еще с 17-й версии дистра. После загрузки с флешки система выдает сообщение следующего содержания:

dracut-initqueu[345]:Warning: Could not boot.
dracut-initqueu[345]:Warning: /dev/root does not exist.
 
Чтобы избавиться от этого, следует взять флешку, воткнуть её в любую машину под осью от Microsoft, и поменять метку диска на LIVE (обязательно большими буквами). Делать смену метки из-под винды, как не печально, самый простой и быстрый способ, ибо тот же gparted под моим Debian Wheezy это наотрез делать отказался, а команы типа mlabel, ntsflabel и иже с ними результата не давали, ссылаясь на какие-то там изьяны в самой флешке (как я понял, от контроллера памяти свистка зависит, сработают эти команды, или нет).

Переименовав флешку, тыкаем её обратно в машину, на которой будем производить установку, и, в меню выбора варианта установки, клацем Tab, и редактируем строку загрузки:

linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2018\x20x86_64 quiet
(у вас может малость отличаться)
на
linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=LIVE quiet 

и жмакаем Enter. Мы по факту просто отредактировали строчку, указав новый лейбл, которым и правда называется сейчас наш свисток с федором. Все, загрузка пойдет как надо.

пятница, 12 июля 2013 г.

ODBC-драйвер для MS SQL Server версии 3.50.0303 или старше

Недавно столкнулся с этой проблемой при попытке запуска 1С 7.7 на машине с Windows 7. Причем, проблема зависит, похоже, от фазы луны, или прочих космических дел, ибо та же 1С без проблем заработала на другой машине с "семечкой". Ситуация следующая: 1С припопытке соединиться с сервером базы данных (проблема возникает только если БД находится на SQL 2005, на 2008-м все работает из коробки) выдает ошибку

Для доступа к базе данных требуется ODBC-драйвер для MS SQL Server версии 3.50.0303 или старше

Никакие создания файлов bin-папке 1С для отключения проверки бла бла бла, или замена odbcbcp.dll, sqlsrv32.dll, sqlsrv32.rll на икспишные, или редактирование файлов, добавление строчек и прочая вздрочь с бубном не нужны, да и не всегда помогают, и по отдельности, и все вместе, и в любых комбинациях. Реальным решением проблемы есть
Секретный релиз платформы v77.27.1 Просто найдите в сети кем-то благородно выложенный архив (тут, к примеру) и установите это решение. И все заработает. Порядок установки приведу ниже: 
  1. Установить платформу из оригинального установщика;
  2. Установить и настроить HASP-ключ (обязательное условие, а то к вам придут врачи);
  3. Переименовать оригинальный файл BkEnd.dll в BkEnd0.dll (0 - это ноль);
  4. Скопировать файлы BkEnd.dll и BkEndUtls.dll из поставки в каталог, куда установлена 1с (например, C:\Program Files\1Cv77\BIN);
Для счастливых обладателей dbf-версии ничего не меняется.
Для обладателей sql-версии, у которых база данных размещается на MS SQL 2005/2008, необходимо соблюсти следующие требования для sql-логина (учетка, под которой 1с подключается к sql):
  • обладание, как минимум правами db_owner;
  • права на VIEW SERVER STATE;

С первым требованием все и так ясно, второе - требует пояснений. Для определения количества соединений к текущей базе данных, 1с обращается к системной таблице sysprocesses. Если у логина отсутствуют права на VIEW SERVER STATE, то будут видны только соединения, осуществленные под своей учеткой, что не совсем хорошо - нужно видеть все соединения с текущей базой, чтобы получать адекватые сообщения об ошибках. Большинство "специалистов" запускает 1с под учеткой SA (или другой, но с соответствующими суперправами), следовательно, у них такой проблемы не стоит. Зато имеется другая проблема - так называемый фоновый процесс сброса грязных страниц из кэша буфера данных, при выполнении которого, не удается запустить 1с в монопольном режиме.
В MS SQL 2005/2008 системная таблица (уже представление, оставленное для обратной совместимости) sysprocesses помечена устаревшей и в следующих редакциях MS SQL будет удалена. Компания Microsoft рекомендует использовать текущие аналоги - так и поступаем :) Для определения соединений к текущей базе данных (в этом исправленном релизе платформы 1с) больше не используется системная таблица sysprocesses (если ms sql 2005/2008, для ms sql 2000 используется).
Для того, чтобы дать права на VIEW SERVER STATE нужно выполнить простой скрипт:
USE master
GO

GRANT VIEW SERVER STATE TO

GO

Все остальные настройки по-умолчанию. Все, на этом проблема решена. Надеюсь, сэкономил кому-то драгоценное время.