1) Скачал DEB пакет HASP лежит тут. Внутри архива DEB. Вот краткая инструкция для Debian x64:

Installing the Sentinel HASP Run-time Environment v.1.15 Perform the following steps to install the Run-time Environment:

(For x64 distributions) Manually install the 32-bit support libraries (x86 compatibility packages) provided by your Linux distribution.
For example: For Debian or Ubuntu, use the command: apt-get install ia32
Disconnect your HASP HL key (if any) from the computer.
Open a terminal window and navigate to the directory containing the downloaded installation file.
As root, enter the following command:
For Ubuntu 32-bit or Debian 32/64-bit: dpkg -i Sentinel_HASP_Ubuntu_DEB_Run-time_Installer.deb
For Ubuntu 64-bit: dpkg -i —force-architecture Sentinel_HASP_Ubuntu_DEB_Run-time_Installer.deb
Optional: To support legacy HASP and Hardlock parallel keys, refer to the instructions in the file INSTALL inside the aksparlnx packages.
Reattach the HASP HL key.

 2) Изменил параметры в /etc/udev/rules.d/

SUBSYSTEM==»usb», ACTION==»add», ENV{DEVTYPE}==»usb_device», NAME=»bus/usb/$env{BUSNUM}/$env{DEVNUM}», MODE=»0644″

и заменить значение параметра MODE на 0666:

SUBSYSTEM==»usb», ACTION==»add», ENV{DEVTYPE}==»usb_device», NAME=»bus/usb/$env{BUSNUM}/$env{DEVNUM}», MODE=»0666″

Симптомы: периодически (примерно раз в день) «теряется» ключ. Как следствие все вылетают из 1С. Вроде бы все ок, тк:

ps aux | grep hasp
root 7585 0.0 0.0 7808 868 pts/0 S+ 10:11 0:00 grep hasp
root 25970 0.0 0.0 1812 360 ? S Sep29 0:00 /usr/sbin/winehasp
root 25972 0.0 0.0 31764 4700 ? Rl Sep29 1:04 /usr/sbin/hasplmd -s
root 25988 0.0 0.0 1792 460 ? S Sep29 0:12 /usr/sbin/hasplm

Но смущает вот такая запись:

dmesg
usb 2-1.4: usbfs: USBDEVFS_CONTROL failed cmd aksusbd rqt 192 rq 129 len 5 ret -110

Честно гуглил, но информации крайне мало. В итоге проблема решилась установкой ключа в другой USB разъем.

# ls /proc/bus/usb/
001 002 devices

Поскольку этих файликов там нет, то сервер 1С предприятия может не находить hasp. Да, есть драйвер hasp от ethersoft, там сделали воркараунд, в скрипте запуска прилинковывают содержимое /dev/bus/usb/ в /proc/bus/usb и еще откуда-то (не помню точно откуда) линкуют devices.

Вариантом решения может быть следующее: прописать в fstab строчку

procbususb /proc/bus/usb usbfs defaults 0 0

После этого будет работать с дровами от алладина, про эзерсовтовские пишут, что тоже работает, но я уже их ставить не стал.

PS
За решение спасибо Александру Г.

Взято с форума Mozilla Россия
1) Инструменты -> настройки
2) Дополнительные -> Основные
3) Редактор настроек -> соглашаемся,что будем осторожны
4) Находим по поиску в редакторе настроек «browser.helperApps.deleteTempFileOnExit», дважды кликаем и выставляем «False»
5) Если же не находим данного параметра,правой кнопкой в любом месте редактора настроек -> создать -> логическое с именем «browser.helperApps.deleteTempFileOnExit» и ставим «False»
6) От себя — выходим из настроек и перезагружаем Thunderbird.

Ну и напоследок скрипт на AutoIT, выполняющий рутинную работу. Работает только с профилем «Profile0″ из файла %APPDATA\profiles.ini’. в противном случае ничего не делает.
Скачать

Все просто. Два пути:
1) Руками снять галку. Редактирование — Установки — Основные — Включить защищенный режим.
2) Через реестр. Вот содержимое reg_файла»

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\Privileged]
"bProtectedMode"=dword:00000000
Добавить можно через командную строку, допустим так
regedit /s "path\to\reg-file.reg
Или любым другим интересным для вас способом.

В настройках оперы (CTRL+F12 -> Расширенные -> Сеть) Выставить значения повыше, чем имеющиеся у вас:

Число подключений к серверу
Общее число подключений

Еще можно отметить пункт «Включить HTTP 1.1 для прокси сервера»

Это все хорошо и работает, но метод «не наш», т.к. бегать по всем пользователям никому не хочется.
В итоге простенький скрипт на AutoIT, который меняет два вышеупомянутых значения. Должен быть запущен с двумя параметрами: первый — «Число подключений к серверу», второй — «Общее число подключений» соответственно. Скрипт принимает только числовые значения от 1 до 128, а противном случае ничего не делает. Не работает под Win98/Me.
Пример:
OperaPrefs.exe 128 128
Должен уточнить, что опера принимает только определенный набор значений (а не диапазон от 1 до 128), но такой проверки в скрипте нет (сразу не знал, потом поленился), если число будет «несовместимым», опера выставит значение «1″

В архиве скомпилированный exe и исходники.

Установка из исходников сводится к нескольким простым шагам.
Как всегда пара ссылок для начала:
Скачать RoundCube можно с официального сайта — http://roundcube.net/download
Официальное руководство по установке — http://trac.roundcube.net/wiki/Howto_Install

Alias /mail /usr/share/roundcube
и выполните /etc/init.d/apache2 reload

/temp
/logs

CREATE DATABASE roundcube;
GRANT ALL PRIVILEGES ON roundcube.* TO username@localhost IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

cd /usr/share/roundcube
mysql -u roundcube roundcube -p < mysql.initial.sql

Итак, если Вы видите это сообщение значит все чуть хуже чем предполагалось.

Что Вам не поможет:

• Загрузка dt файла в файл-серверном варианте и выполнение полного тестирования и исправления;
• Загрузка dt файла в файл-серверном и проверка 1CD файла утилитой chkdbf.exe

Другими словами если у Вас нет выгрузки данных средствами PostgreSQL дела плохи. Цитата из партнерского форума:

Единственным способом восстановления данной информационной базы является отправка выгрузки информационной базы на v8@1c.ru.


Резонным возникает вопрос что же произошло? Скорее всего в какой-то момент времени в системную таблицу files «попало» две записи с одинаковым первичным ключом, а именно filename. Как это могло произойти, пока лично для меня, остается загадкой, тк на таблицу есть вот такое ограничение:

CONSTRAINT files_pkey PRIMARY KEY(filename)


После того как стало понятно, что произошло и что точно не поможет разберем как можно исправить ситуацию. Схема последовательности действий следующая:

1.Восстановить базу из копии (сделанной pg_dump) посредством pg_restore
2.В консоли или в pgAdmin выполнить запрос:
select filename, max(creation), max(modified), max(attributes), max(datasize)
from files
group by filename
having count(*) > 1
order by filename


3.Из повторяющихся записей оставьте только запись с максимальным значением поля modified, а остальные записи удалить оператором:

delete from files
where filename = "имя файла" and modified = "устаревшая дата"


например:

delete from files
where filename = "071523a4-516f-4fce-ba4b-0d11ab7a1893.pfl" and modified = "2009-11-17 15:33:48"


4.Повторно выгрузить базу средствами 1С

На данный момент нам не известны никакие другие способы решения проблемы (кроме отправки базы 1с).

Если Вы не используете штатные средства СУБД для архивации баз данных, мы настоятельно рекомендуем начать это делать уже сегодня , тк иногда (как в подобном случае) это единственный шанс восстановить Вашу базу.

ps
Описанный выше способ является прямым нарушением лицензионного соглашения 1С, но именно такая рекомендация озвучивается на партнерском форуме.

На днях случился… Ну как бы сказать… «Эпический фейл». Заключался он в том, что у нас просто «упали» все базы. Сразу хочу сообщить, что PostgreSQL тут совершенно не причем, во всем виновата наша халатность. Так вот почему это случилось и с чего началось я и хотел бы рассказать.

Сейчас у нас все хорошо, и что самое главное… Выводы сделаны!

Когда-то давно, когда мы только начали использовать PostgreSQL (писать правильно нужно именно так) в качестве СУДБ, мы обратили внимание на странный процесс который постоянно вызывал дисковую активность: postgres: stats collector process

Если очень коротко, то этот процесс собирает информацию и отчетность о серверной активности (серверной в смысле PostgreSQL) и сбрасывает эту информацию в файл по-умолчанию /global/pgstat.stat.

Причем, судя по исходным кодам (да, пришлось посмотреть из любопытства) делает это довольно часто:

pgsql/src/backend/postmaster/pgstat.c

/* ----------
* Paths for the statistics files (relative to installation's $PGDATA).
* ----------
*/
#define PGSTAT_STAT_FILENAME "global/pgstat.stat"
#define PGSTAT_STAT_TMPFILE "global/pgstat.tmp"

/* ----------
* Timer definitions.
* ----------
*/
#define PGSTAT_STAT_INTERVAL 500 /* How often to write the status file;
* in milliseconds. */

И все вроде бы не плохо, но судя по анализу команды atop происходит попытка записи данных и сразу же идет отмена. Возникло подозрение, что активность процесса обратно пропорциональна его полезности. Кроме того напрягало постоянное высокое значение параметра avio. Одной из возможных причин высокого значения параметра avio нам показалась как раз активность процесса stats collector.

Начался процесс поиска информации с помощью Google Ничего вразумительного мы в принципе так и не нашли. Тогда я решил попросить помощь зала.

http://archives.postgresql.org/pgsql-general/2009-12/msg00903.php

Вот текст сообщения:

From: Лев Ласкин
To: pgsql-general@postgresql.org
Subject: stats collector process: WRDSK = WRDSK_CANCEL?
Date: Tue, 22 Dec 2009 12:30:05 +0300
Message-id: <4B30919D.9030903@gmail.com>

db0: ~ # ps auxww | grep postgre
postgres 11296 4.3 0.1 24244 13028? Ss Nov24 1734:25 postgres: stats collector process
Why WRDSK = WRDSK_CANCEL? So it should be? Perhaps we were wrong in the settings.
Who can help anything in this matter?

Откликнулся комрад Magnus Hagander (один из «коммитеров» патчей для PostgreSQL). Он ответил следующее

WRDSK_CANCEL is data that was written, but deleted before it was
flushed to disk. That is normal behaviour for the stats temp file,
which is written and deleted within half a second.

8.4 will do a lot less writes here, but on 8.4 it's perfectly normal.

Все бы здорово Magnus, но на тот момент PostgreSQL 8.4 вышел, а вот патчей для адаптации 1С нет. Поэтому у нас без вариантов…Как оказалось Magnus еще в 2008 «запаривался» на эту тему и предложил вот такой вариант:

http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg110417.html

This would make it possible to symlink or mount that directory off to a
ramdrive (for example).

It’s not a perfect solution, but it would at least give a better tool
than we have today, no?

//Magnus
Чтож, мы так и сделали: ln -s /dev/shm/globdal /pgsql/global

Более stats collector process нас не мучал.

Ps
Продвинутые товарищи уже догодались что же все таки у нас случилось, но об этом в следующий раз..

В групповых политиках AD в политиках ограниченного использования программ запретите запуск файла snatch.exe.
В правилах касперского антихакера запретите любую сетевую активность для snatch.exe.
Если у вас продвинутый шлюз/прокси можете настроить блокировку там.
Все это временные меры, по крайней мере до тех пор, пока антивирусные вендоры не выпустят обовления.