Android 4.4 KitKat и Cisco VPN Client

На предыдущем телефоне были попытки цепляться к работе с телефона, но успехом они не увенчались. Либо в силу древнего андроида 4.0, либо в силу кривизны рук. Став обладателем девайса с KitKat решил посмотреть, что поменялось. И всё завелось без проблем. В Настройках, Беспроводные сети, Ещё, VPN:

Жмем в +:

Тип шифрования IPSEC Xauth PSK. Идентификатор группы - это название группы. Общий ключ = групповой ключ.

Логин и пароль он запросит при подключении, можно и запомнить их. Можно указать соединение как постоянное.

Про Ctrl+Z

(перевод поста отсюда)

Сочетание клавиш Control+Z используется, чтобы "усыпить" процесс, посылая ему сигнал SIGSTOP, который не может быть перехвачен программой. А вот сочетание клавиш Control+C используется для того, чтобы "прибить" процесс с помощью посыла процессу сигнала SIGINT, который может быть перехвачен выполняющейся программой, чтобы она могла корректно освободить ресурсы перед завершением или вообще проигнорировать его.

Если вы отправили процесс "в спячку", командная оболочка сообщит вам об этом примерно так:

[1]+  Stopped                 yes

Однако, если вы "убьёте" процесс, вы не увидите какого-либо подтверждения от командной оболочки. Для усыплённых процессов доступно несколько действий. Например, выполнив команду:

fg

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

Выполнив команду:

bg

для приостановленной программы, мы позволим ей продолжать выполняться в фоновом режиме (однако, вывод программы всё равно будет идти на терминал).

Если вы желаете прекратить выполнение приостановленной программы, вам не обязательно возобновлять ее выполнение с помощью команды fg. Достаточно команды:

kill %1

Если вы приостановили выполнение нескольких процессов, запустите команду:

jobs

Её вывод будет содержать список приостановленных процессов:

[1]-  Stopped                 pianobar
[2]+  Stopped                 yes

Используя %#, где # - это номер задачи (цифра в квадратных скобках в выводе jobs), вместе с командами bg, fg, или kill, вы можете совершать действия над необходимым процессом.

Если HASP License Manager не раздает лицензии

Ковырялись мы тут с переводом сервера 1C на Linux. Почти все проблемные места были закрыты. Но тут снова перестали браться лицензии с ключа. Начали вспоминать, что могли сломать (до этого-то работало), перезапускать что попало, менять версии драйверов hasp - всё было без толку. И hasp прокинулся на виртуальную машину, и его драйвера стартанули, и соединение между менеджером лицензий и драйверами активна. А оказалось всё очень просто. При конфигурационном файле по-умолчанию клиент 1С ищет сервер лицензий broadcast-ом:

[NH_TCPIP]

;;NH_SERVER_ADDR = <Addr1>, <Addr2> ; IP addresses of all the NetHASP 

; License Managers you want to search.

; Unlimited addresses and multiple

; lines are possible.

; Possible address format examples:

;  IP address:      192.114.176.65

;  Local Hostname:  ftp.aladdin.co.il

;;NH_PORT_NUMBER = <Num> ; Set the TCP/IP port number. This is

; optional. The default number is 475.

;;NH_TCPIP_METHOD = TCP or UDP ; Send a TCP packet or UDP packet

; Default:  UDP

;;NH_USE_BROADCAST = Enabled or Disabled; Use TCPI/IP Broadcast mechanism.

; Default:  Enabled

Даже если указать конкретный NH_SERVER_ADDR. Он просто брал лицензию с соседнего сервера. Ну и в купе с тем, что сервер лицензий не обращается к ключу и не показывает его до первого обращения к нему от клиента, в AKS Monitor он (ключик) не отображается. Отключив широковещательный поиск сервера и указав IP-адрес необходимого нам, получаем желаемый результат. 

417 Expectation Failed

На днях потребовалось научить одну .net-программулину работать через прокси. Быстренько были внесены изменения в интерфейс настроек, заполнено свойство Proxy объекта класса HttpWebRequest. Но тут что-то пошло не так. Страничка в Firefox открывалась, а вот при попытке выполнить запрос через софтину мы получали ответ от сервера 417 Expectation Failed. После прочтения материала и просмотра заголовков, отправляемых приложением, стало понятно, что объект HttpRequest при отправке POST-запроса автоматически добавляет заголовок Expect. А прокси-сервер Squid3 по умолчанию отвергает такие запросы с кодом ошибки 417:

#  TAG: ignore_expect_100       on|off

#       This option makes Squid ignore any Expect: 100-continue header present

#       in the request. RFC 2616 requires that Squid being unable to satisfy

#       the response expectation MUST return a 417 error.

#

#       Note: Enabling this is a HTTP protocol violation, but some clients may

#       not handle it well..

#Default:

#ignore_expect_100 off

Хотя правильнее отключить применение этого заголовка при работе через прокси:

         string postData = String.Format("lg={0}&pw={1}", login, pass);

            HttpWebRequest request = (HttpWebRequest)WebRequest.Create(LOGIN_URL);

            request.Proxy = proxy;

            request.CookieContainer = new CookieContainer();

            request.CookieContainer.Add(cookie);

            request.Method = WebRequestMethods.Http.Post;

            request.AllowWriteStreamBuffering = true;

            request.ProtocolVersion = HttpVersion.Version11;

            request.AllowAutoRedirect = true;

            request.ContentType = "application/x-www-form-urlencoded";

            request.Timeout = REQTIMEOUT;

            request.ServicePoint.Expect100Continue = proxy == null; 

 

Тернарный оператор на python

Нравилась мне эта конструкция в .net. Её аналог в мире python:

i = 5 if a > 7 else 0

Если верить этому, то транслируется в:

if a > 7:
   i = 5
else:
   i = 0

Долго выполняется .GetRequestStream()

Во время отладки случайно заметил, что для пустого метода POST создание запроса выполняется очень долго. Поход в гугл выдал это.

Как оказалось, HttpWebRequest по-умолчанию настроен на автоопределение настроек прокси-сервера, что есть очень медленно. Чтобы этого не происходило, при инициализации HttpWebRequest необходимо:

<HttpWebRequest>.Proxy = null;

Еще один любопытный момент проявляется при использовании опции:

 <HttpWebRequest>.AllowAutoRedirect = true;

При редиректе на страницу авторизации, которая устанавливает куку, эту куку из response мы получить не сможем, потому что ее там просто нет. Так что этот параметр в false и ручками. 

UPDATE FROM SELECT в PostgreSQL

В процессе изучения PostgreSQL столкнулся со странным поведением оного при попытке выполнить подобный запрос:

UPDATE
    Table
SET
    Table.col1 = other_table.col1,
    Table.col2 = other_table.col2
FROM
    Table
INNER JOIN
    other_table
ON
    Table.id = other_table.id

Все записи перезаписывались первой записью из результата INNER JOIN. Зато отлично сработал такой код:

     UPDATE  user u
     SET     balance = balance + p.amount
     FROM    (
        SELECT  user_id, SUM(amount) AS amount
        FROM    payment
        WHERE   id IN (36, 38, 40)
        GROUP BY
                user_id
      ) p 

      WHERE u.id = p.user_id