xl2tpd после подключения наглухо вешает систему

Вот так вот внезапно. Жили, не тужили, пользовались VPNкой, а тут здравствуйте: подключаемся, секунд 15 и полное зависание системы без сообщений о ошибках. За это время я успевал по привычке открыть remmina и попытаться подключиться. А так как собирал я ее из исходников, первой под горячую руку напрасно попала именно она - мол, что-то после обновлений сломалось. Почесав за ухом и убедившись, что все валится именно после поднятия подключения L2TP, а не ipsec задумался. Было бы еще над чем. В логах было пусто. Решил попробовать подключиться из консоли без Иксов. Что-то повалилось. Что-то содержало сообщение:

BUG: soft lockup - CPU#1 stuck for 23s! [pppd:<PID>]

Отсюда гуглится ВОТ ЭТО. Опять Арчеводы)) Оказывается, линь убивается выстрелом петлей в таблице маршрутизации. Поднялась ipsec-ассоциация до узла 1.2.3.4, поднялся l2tp-тунель до 1.2.3.4, создался маршрут до 1.2.3.4 через ppp0. Пакеты, идущие в тонель, после инкапсуляции заворачивались ядром в ipsec, а его пакеты, желая попасть на 1.2.3.4 попадали опять в тунель. Тут-то и капец ужику.
Решается убиением в скрипте ip-up маршрута до шлюза через ppp0 после установления соединения.
Пока для меня остался вопрос, что именно поменялось после обновления. Начал добавляться этот маршрут, которого раньше не было, что как-то сомнительно. Также сомнительно, что пакеты ipsec при наличии такого маршрута до этого его игнорировали, а тут начали учитывать. Хотя, помнится, я настраивал где-то strongSwan на игнор интерфейса ppp0, но к маршрутизации в Линукс это вряд ли имеет отношение. Так что, откуда-то всплыл этот бессмысленный маршрут, похоже...

Неинформативные сообщения strongswan

Потребовалось подключиться по IPSec к новому межсетевому экрану. Решил попробовать strongswan, так как openswan отсутствует в репозитариях debian jessie. Выжимка из того, на чём удалось навернуться.
Основной конфиг /etc/ipsec.conf, общий ключ в /ets/ipsec.secrets. Для применения изменений необходимо выполнить sudo ipsec reload. Но данная команда не отображает никакой информации об ошибках/опечатках в конфигурационном файле в отличие от sudo ipsec restart. Другие команды можно посмотреть здесь.
Для подключения-отключения необходимо выполнить: sudo ipsec up|down <connection name>.
После ее вызова выводится лог подключения.
Пока не указал в явном виде использовать IKE v1 (keyexchange=ikev1) удаленная сторона просто молчала, strongswan повторял попытки установления соединения.
Также потребовалось явно указать список протоколов шифрования для IKE (ike=aes128-sha1-modp1536,aes128-md5-modp1536,3des-md5-modp1024,aes128-sha1-modp1024,aes256-sha-modp1024,3des-md5-modp1024). До этого момента соединение обрывалось на первом шаге с ошибкой NO_PROPOSAL_CHOSEN.
Далее я получил ошибку no shared key found. В конфигурационном файле для подключения должны присутствовать опции left=%any и right=1.2.3.4, соответствующие адресам узлов, участвующих в ассоциации. Опции leftid и rightid в моем случае необязательны, я их не указывал. В файле /etc/ipsec.secrets общий ключ должен быть записан в виде:

%any 1.2.3.4 : PSK "sTrong$ecret"

Слева направо: адреса участников ассоциации, двоеточие (отделенное пробелами), тип записи PSK (общий ключ), собственно, ключ обязательно в кавычках. Без кавычек ключ, кажется, в base64. Подробнее тут.
Далее я снова получил ошибку NO_PROPOSAL_CHOSEN, но уже во второй фазе IKE - Quick Mode. Казалось бы, стороны снова не могут согласовать алгоритмы шифрования, но нет. Помог блог какого-то замечательного человека. Спасибо тебе, огромное!) Оказалось, что нужно указать корректную, с точки зрения межсетевого экрана, rightsubnet=1.2.3.4/32, вместо rightsubnet=0.0.0.0/0, указывающую только на сам межсетевой экран. После чего всё благополучно взлетело, а я пошел ковыряться дальше.
Примерный файл конфигурации:

conn vpn
# Режим работы IPSec - транспортный (туннельный и т.д.)
type=transport
# Алгориты шифрования/аутентификации
ike=aes128-sha1-modp1536,aes128-md5-modp1536,3des-md5-modp1024,aes128-sha1-modp1024,aes256-sha-modp1024,3des-md5-modp1024
ikelifetime=86400s
lifetime=3600s
# Версия протокола IKE v1
keyexchange=ikev1
rekey=yes
forceencaps=yes
# Режим запуска - в момент обращения к защищаемому узлу
auto=route
# Left
# Адрес с интерфейса, через который идет маршрут по-умолчанию
left=%any
# Добавлть разрешающие правила в локальный межсетевой экран
# leftfirewall=yes
# Right
# Адрес узла, с которым необходимо соединиться
right=1.2.3.4
# Подсеть за узлом, которая будет защищаться соединением, фильтр протокола и порт
rightsubnet=1.2.3.4/32[udp/1701]

 Для настройки L2TP поверх IPSec с помощью демона xl2tpd хорошо подходит инструкция от поклонников Арча.
PS. После обновления strongSwan до 5.4 благополучно работавшее соединение снова отказалось подключаться с той же ошибкой NO_PROPOSAL_CHOSEN. Благодаря этому посту и описанию параметра esp = в официальной документации было выяснено, что в 5.4 был изменен алгоритм шифрования по умолчанию:

esp = <cipher suites>

...

Defaults to aes128-sha256 (aes128-sha1,3des-sha1 before 5.4.0). 

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

Настройка Chromium для использования SPNEGO

Даже скорее не так. Информации на просторах интернета о том, какой параметр - AuthServerWhitelist - за это отвечает - воз и маленькая телега. Официальная документация: https://dev.chromium.org/administrators/policy-list-3#AuthServerWhitelist. В основном на тех самых просторах, правда, предлагают его тулить по старинке флагами при запуске браузера. Но есть отсылки и к политикам. И вот тут закопалась главная свинья - я не умею читать. В инструкции по политикам сказано чёрным по белому:

Set Up Policies

Policy configuration files live under /etc/chromium for Chromium, and under /etc/opt/chrome for Google Chrome.

А я долго и упорно пытался их положить в /etc/opt/chromium и т.д. Для SPNEGO конфигурационный файл должен выглядеть так:

cat /etc/chromium/policies/managed/example-corp.json  

{ "AuthServerWhitelist": "*.domain.local",

"AuthNegotiateDelegateWhitelist": "*.domain.local" }

Второй параметр нужен для указания доменов, для которых включено делегирование учетных данных. В том, что всё успешно применилось можно убедиться открыв chrome://policy/.

Контроллер домена не берёт время с сервера точного времени

На команду

w32tm /resync

отвечает "Синхронизация не выполнена, поскольку нет доступных данных о времени."
Команда

w32tm /monitor

кажет, примерно, следующее:
DC1.domain.local *** PDC ***[[::1]:123]: 
    ICMP: 0ms задержка 
    NTP: +0.0000000s смещение относительно DC1.domain.local 
        RefID: 'LOCL' [0x4C434F4C] 
        Страта: 1 

Т.е. время берётся с локальных часов, сервер присвоил себе страту 1. Хотя тут есть один ньюанс)) Никсовые машины с такого сервера время брать отказываются. То ли в силу того, что источник LOCL, то ли страта отображается как 1, а на деле 16. Ответ нашелся здесь. В групповую политику по умолчанию внесли Включить NTP-клиент Windows. И она применилась к контроллеру домена. Ключи реестра из Policies переопределили стандартные и сервер пытался брать время сам с себя, после чего уходил в себя брать время со своих часов.

Исключить из одного файла строки, присутствующие в другом файле

Всё, как обычно, оказалось тривиально. Прямо как говорила наш преподаватель по мат. анализу=) У команды grep есть подходящий для этой задачи набор флагов:

grep -v -x -f except.txt source.txt, где

• -v  отобрать не совпавшие с шаблоном строки
• -x сравнивать строку целиком
• -f except.txt файл с набором шаблонов для поиска, разделенных переносом строки
• source.txt - исходный файл для поиска и исключения вхождений из файла except.txt (естественно, его можно заменить на подачу через пайп)

 

CIFS с kerberos-авториацией

Решил окучить вопрос подключения windows-шар с использованием билета kerberos. Небезопасно как-то хранить plain-текстом доменные учётные данные, а вводить каждый раз ручками - не наш метод. В принципе, оказалось, что всё, что надо, есть из коробки. Потребуются пакеты:

sudo apt-get update 

sudo apt-get install krb5-user cifs-utils keyutils

 При грамотно настроенном DNS настройка kerberos-клиента сводится к указанию REALM домена windows по-умолчанию (рекомендуется указывать в верхнем регистре, например EXAMPLE.COM), который будет запрошен при установке и может быть изменен в /etc/krb5.conf. Если всё правильно, то с получением билет не должно возникнуть проблем:

kinit vasiliy
Password for vasiliy@EXAMPLE.COM:
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: vasiliy@EXAMPLE.COM
Valid starting       Expires              Service principal
22.06.2015 21:28:02  23.06.2015 07:28:02  krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 23.06.2015 21:27:57

Вывод команды klist отобразит информацию о полученном билете. Чтобы монтировать сетевую шару без необходимости прав root внесем в /etc/fstab следующую строку:

//host.example.com/development /home/vasiliy/Dev cifs rw,user,noauto,sec=krb5,username=vasiliy,domain=EXAMPLE.COM 0 0

Точку монтирования /home/vasiliy/Dev, естественно, надо создать. Также хочу указать на необходимость указания  настроек подключения cifs именно в fstab - с командой строки они браться не будут. Если не указывать username и domain, то будут использоваться из хранилища ключей (?). Т.е. строку можно будет использовать любому пользователю станции. Монтируем и отмонтируем командами, соответственно:

mount /home/vasiliy/Dev
umount /home/vasiliy/Dev

ЗЫ. Ошибка вида:

mount error(128): Key has been revoked 

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) 

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

О дырявых роутерах...

Звонит мне, значится, сегодня друг и говорит.

Что-то с Контактом какая-то фигня. Работает-работает, бах, сваливается на страницу авторизации. А на этой странице кроме кнопки войти всё остальное не работает и выдаёт ошибку. Вчера весь день комп на предмет вирусной дряни шмонал - ничего. А сегодня заметил, что и телефон при работе через wi-fi вытворяет то же самое. Сейчас подключил напрямую Интернет без роутера - вроде бы всё нормально. Может быть проблема в роутере?

Ну тут мне вспомнился давешний пост на OpenNet. Роутер Asus RT-N10R. Попросил сделать вывод nslookup:

Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\User>nslookup vk.com Server: UnKnown Address: 178.208.81.126 Name: vk.com Address: 178.208.81.126

А должно быть как-то так:

C:\Users\User>nslookup vk.com
Server: router.asus.com
Address: 192.168.1.1 

Non-authoritative answer:
Name: vk.com
Addresses: 2a00:bdc0:3:103:1:0:403:901
2a00:bdc0:3:103:1:0:403:902
2a00:bdc0:3:103:1:0:403:903
87.240.131.99
87.240.131.97
87.240.131.120

Т.е. роутер отдавал клиентам сети в качестве dns-сервера 178.208.81.126 - адрес злоумышленника. При обращении к этому адресу 178.208.81.126 вылезла страничка "типа, одноклассников". В коде страницы честно присутствует:

<!DOCTYPE html>

<!-- saved from url=(0013)http://ok.ru/ -->

<html class=" an

Если запросить vk.com - вылезет страничка входа Контактика. Сброс роутера проблему временно решил. Обновили до последней прошивки. При возможности дополню.
PS. Будьте внимательны, используйте двухфакторную аутентификацию.
PS2. Аналогичный случай

squid3 и неожиданно помирающая доменная авторизация

Однажды в понедельник неожиданно умерла корпоративная прокси на squid. У пользователей она съезжала на basic авторизацию, вместо доменной. В cache.log на каждый запрос сыпалось:

authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. '

 Что сбило с толку, так это то, что перезапуск сервиса на какое-то время решал проблему. Минут на 10-15. И потом всё повторялось снова и снова. В какой-то момент sudoedit руганулся на недостаток памяти, хотя df -h радовал свободным пространством. Тут-то коллега и нашёл ЭТО. У нас исчерпались inodЫ. Вывод df -i это подтвердил. И причина была та же самая. SARG, который бесконтрольно плодил свои отчёты каждый день, неделю и месяц. Найти врага можно командой:

for i in /*; do echo $i; find $i | wc -l; done

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

SQL Server 2012 Express, VipNet и KB2992611

Как-то неожиданно помер локальный SQL Server 2012. Т.е. как сказать, помер... Служба жива, но достучаться до нее никто не мог. Ни приложение, её использующее, ни Managment Studio с однотипной ошибкой:

Подключение к серверу успешно установлено, но затем произошла ошибка при входе. (provider: Поставщик общей памяти, error: 0 - С обоих концов канала отсутствуют процессы

В журнал Windows сыпались сообщения:

 Google порадовал ссылкой на форум:
http://www.infotecs.ru/forum/index.php?showtopic=8032&st=120
Тут-то я и вспомнил, что накануне прилетели обновления, а вместе с ними и KB2992611. И VipNet есть у меня. Удалил обнову, поехало. Читаю. Найду еще какую информацию - дополню.

Продолжение истории от 14 июня 2016 года

И снова здравствуйте. После обновлений сдохло подключение по RDP c примерно следующим текстом:

Произошла ошибка при проверке подлинности.
Не удается установить связь с локальной системой безопасности

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

Вместе с ним прихватило и локальный MSSQL-сервер, служба которого наотрез отказывалась даже запускаться с ворохом ошибок в журналах. В Системе: Service Control Manager 7024. В приложениях: MSSQL$SQLEXPRESS 26011, 17182, 17826, 17210 с жалобами на проблемы с библиотекой безопасности, вплоть до отсутствия security.dll и на невозможность установить SSL-соединение.
Удаление обновлений не принесло желаемого результата. На просторах Интернет предлагалось запустить cspclean.exe для вычищения хвостов CryptoPro CSP. Но мне это не помогло. Точнее как, не помогло. После ребута винда падала с синим экраном 0x000000f4. Помогал запуск последней удачной конфигурации (первый раз в жизни=), но он, понятное дело, все хвосты возвращал взад. На тот момент на компе уже не было ни крипто про, ни випнета, ни вигейта. Начал поочередно устанавливать и удалять этот софт. Что установка, что удаление випнет приводила к тому же синему экрану. А вот после установки vipnet_csp_rus_4.2.5.35526_beta указанные выше проблемы ушли.

Немного о часовых поясах в Python 2.7

Началось всё с того, что я столкнулся с невозможностью сравнить абсолютное и относительное время в Python. PostreSQL возвращал абсолютное, а datetime.now() относительное. Про разницу очень хорошо расписано здесь:
http://asvetlov.blogspot.ru/2011/02/date-and-time.html
Проблема оказалась лишь в том, что dateutil не в курсе последнего изменения часовых поясов. Смещения он берет из time.timezone, а оно в свою очередь возвращает -11 для моего часового пояса. Откуда он его берет пока не разобрался. Поставил pytz и tzlocal по рекомендации отсюда:
http://regebro.wordpress.com/2012/09/12/presenting-tzlocal-a-simple-way-to-get-your-local-timezone-for-pytz/

>>> from tzlocal import get_localzone

>>> from datetime import datetime

>>> print(datetime.now(get_localzone()))

2014-11-27 08:31:01.458893+10:00 

Не работал squid_ldap_group

Настраивал связку Squid+AD. Negotiate авторизация завелась без проблем, захотелось, чтобы пользователи ходили по группам из LDAP. По мануалам настроил external acl, но оно не взлетело. В cache.log при запуске сыпалось:

2014/11/12 10:04:41| helperOpenServers: Starting 5/5 'squid_ldap_group' processes

2014/11/12 10:04:41| commBind: Cannot bind socket FD 31 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| commBind: Cannot bind socket FD 32 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| ipcCreate: Failed to create child FD.

2014/11/12 10:04:41| WARNING: Cannot run '/usr/lib/squid3/squid_ldap_group' process.

2014/11/12 10:04:41| commBind: Cannot bind socket FD 34 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| commBind: Cannot bind socket FD 35 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| ipcCreate: Failed to create child FD.

2014/11/12 10:04:41| WARNING: Cannot run '/usr/lib/squid3/squid_ldap_group' process.

2014/11/12 10:04:41| commBind: Cannot bind socket FD 37 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| commBind: Cannot bind socket FD 38 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| ipcCreate: Failed to create child FD.

2014/11/12 10:04:41| WARNING: Cannot run '/usr/lib/squid3/squid_ldap_group' process.

2014/11/12 10:04:41| commBind: Cannot bind socket FD 39 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| commBind: Cannot bind socket FD 40 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| ipcCreate: Failed to create child FD.

2014/11/12 10:04:41| WARNING: Cannot run '/usr/lib/squid3/squid_ldap_group' process.

2014/11/12 10:04:41| commBind: Cannot bind socket FD 41 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| commBind: Cannot bind socket FD 42 to [::1]: (99) Cannot assign requested address

2014/11/12 10:04:41| ipcCreate: Failed to create child FD.

2014/11/12 10:04:41| WARNING: Cannot run '/usr/lib/squid3/squid_ldap_group' process.

Вилы были в том, что squid был собран с поддержкой ipv6, и он пытался взаимодействовать со своими плагинами с помощью ipv6. Чтобы этого избежать, нужно явно указать, что необходимо использовать ipv4:

external_acl_type ldap_verify ipv4 %LOGIN /usr/lib/squid3/squid_lda...

Опять убил обновлениями...

В очередной раз решил обновить домашний калькулятор. Обновлений скопилось много. И, как обычно, что-то пошло не так. Windows после перезагрузки сказала:

Не удалось настроить обновления Windows. 

Выполняется отмена изменений

Очистка папки Downlods с обновлениями к желаемому эффекту не привела. В безопасном режиме оно все равно пыталось ставить обновления с тем же успехом. Помогла команда:

dism.exe /image:G:\ /cleanup-image /revertpendingactions

Запускал ее из консоли, полученной в режиме востановления. Диск G: - системный раздел с папкой Windows. Оно призадумалось, выдало ошибку, но в то же время статус: successfully. После этого Окошки нарисовали то же самое сообщение об отмене изменений, но процесс пошел и оно с горем пополам загрузилось.

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 

Сброс автоинкремента в MS SQL

Для того, чтобы установить текущее значение автоинкремента в MS SQL необходимо выполнить:

DBCC CHECKIDENT ('[DBName].[dbo].[TableName]', RESEED, startValue)

Где startValue соответствует значению, с которого + 1 начнется нумерация при выполнении следующей INSERT.