Просто мои записки и не более того, как раньше говорил апач "Move along, nothing to see here ;)"
Search This Blog
Monday, March 16, 2015
Wednesday, March 11, 2015
Friday, February 13, 2015
Cisco AIR LAP-1141 to AIR AP-1141, converting AP from CAPWAP to autonomous
Cisco AIR LAP-1141 - Lightweight Access Point (L letter before AP) controller-based (WLC)
Cisco AIR AP-1141 - Standalone (Autonomous) Access Point
I have at work two Cisco AP-1141. Thats great wireless stations and i like how it works. Few days ago we bought two more. But by mistake new access points were LAP. I dont have Cisco wireless controller at work, its very expensive and useless for us. So i was faced with task of reconfigure LAP 1141 to AP 1141. After searching some time i found that my task can be solved by changing IOS image on device.
First of all, i needed standalone AP IOS image archive. If you has original Cisco image for standalone AP downloaded from cisco.com thats greate. I did not have it. So i download it from my access point. To store image I use tftp server.
1. Setup TFTP server
I'm using Arch linux on laptop so config file for Arch(from official wiki)
I added only -c in ExecStart to allow create new files when uploading
*TFTP server configuration has been moved to /etc/conf.d/tftpd. Please update /etc/conf.d/tftpd and remove /etc/systemd/system/tftpd.service
/etc/systemd/system/tftpd.service
/etc/conf.d/tftpd
2. Uploading image archive to tftp (Cisco manual)
3. When upload finished, everithing like here, connect to LAP Cisco device and run commands:
After boot command device will boot uploaded image, and here we go, Cisco AIR AP-1141 stanbalone autonomous access point
Have fun ;)
IOS images:
*.k9w7.* - autonomous IOS
*.k9w8.* - full lightweight IOS (this is what is bundled in the WLC .aes image, and is factory installed on "mesh" APs)
*.rcvk9w8.* - lightweight recovery image - this is factory installed on lightweight APs, unless a "mesh" image is specified; it lacks radio firmware
Cisco AIR AP-1141 - Standalone (Autonomous) Access Point
I have at work two Cisco AP-1141. Thats great wireless stations and i like how it works. Few days ago we bought two more. But by mistake new access points were LAP. I dont have Cisco wireless controller at work, its very expensive and useless for us. So i was faced with task of reconfigure LAP 1141 to AP 1141. After searching some time i found that my task can be solved by changing IOS image on device.
First of all, i needed standalone AP IOS image archive. If you has original Cisco image for standalone AP downloaded from cisco.com thats greate. I did not have it. So i download it from my access point. To store image I use tftp server.
1. Setup TFTP server
I'm using Arch linux on laptop so config file for Arch(from official wiki)
I added only -c in ExecStart to allow create new files when uploading
*TFTP server configuration has been moved to /etc/conf.d/tftpd. Please update /etc/conf.d/tftpd and remove /etc/systemd/system/tftpd.service
[Unit]
Description=hpa's original TFTP daemon
[Service]
ExecStart=/usr/bin/in.tftpd -c -s /srv/tftp/
StandardInput=socket
StandardOutput=inherit
StandardError=journal
/etc/conf.d/tftpd
TFTPD_ARGS="-c -v -s /srv/tftp/"
2. Uploading image archive to tftp (Cisco manual)
archive upload-sw tftp://10.1.1.64/c1140-k9w7-mx.124-21a.JA1.tar
3. When upload finished, everithing like here, connect to LAP Cisco device and run commands:
debug capwap con cli
conf t
boot manual
reload
After device reboot you should see the ap: prompt.
If you issue a set command you'll see a few variables that you can change.set IP_ADDR 10.1.1.21
set NETMASK 255.255.255.0
set DEFAULT_ROUTER 10.1.1.1
tftp_init
ether_init
flash_init
tar -xtract tftp://10.1.1.64/c1140-k9w7-mx.124-21a.JA1.tar flash:
set BOOT flash:/c1140-k9w7-mx.124-21a.JA1/c1140-k9w7-mx.124-21a.JA1
set MANUAL_BOOT no
set MODE_BUTTON yes
set
boot
After boot command device will boot uploaded image, and here we go, Cisco AIR AP-1141 stanbalone autonomous access point
Have fun ;)
IOS images:
*.k9w7.* - autonomous IOS
*.k9w8.* - full lightweight IOS (this is what is bundled in the WLC .aes image, and is factory installed on "mesh" APs)
*.rcvk9w8.* - lightweight recovery image - this is factory installed on lightweight APs, unless a "mesh" image is specified; it lacks radio firmware
Monday, January 26, 2015
resolv.conf
nameserver 8.8.8.8
nameserver 4.2.2.2
# some magical options
options timeout:1 attempts:1
Labels:
configuration,
dns,
linux,
nameserver,
resolv,
resolv.conf
Monday, November 24, 2014
django project + gunicorn + supervisord + logrotate
/etc/supervisord.conf
/opt/prj/gunicorn.conf.py
/etc/logrotate.d/supervisor
If you dont want use supervisord, gunicorn can write logs by it self (with standard logging)
Don't forget set "logconfig" option in gunicorn configuration
Logging config for example:
/opt/prj/gunicorn.log.conf
[supervisord]
http_port=/var/tmp/supervisor.sock
logfile=/var/log/supervisor/supervisord.log
logfile_maxbytes=50MB
logfile_backups=20
loglevel=info
pidfile=/var/run/supervisord.pid
nodaemon=false
minfds=1024
minprocs=200
[supervisorctl]
serverurl=unix:///var/tmp/supervisor.sock
[program:guni_prj]
command=/usr/bin/gunicorn prj.wsgi -c /opt/prj/gunicorn.conf.py
directory=/opt/prj
user=prjuser
autostart=true
autorestart=true
log_stdout=true
log_stderr=true
#redirect_stdout=true
redirect_stderr=true
logfile=/var/log/supervisor/guni_prj.log
logfile_maxbytes=50MB
logfile_backups=20
/opt/prj/gunicorn.conf.py
bind = ['127.0.0.1:8090']
workers = 2
worker_class = 'gevent'
user = 'prjuser'
group = 'prjgroup'
daemon = False
import os
chdir = os.path.dirname(os.path.abspath(__file__))
# logging.handlers.WatchedFileHandler # python logging file handler, safe for logrotate scripts
# logconfig = '%s/gunicorn.log.conf' % os.path.dirname(os.path.abspath(__file__)) # path to standart logging conf
# accesslog = '-' # logging to stderr
# errorlog = '-' # logging to stderr
# accesslog = '/var/log/prj/guni_prj_access.log' # simple logging to file
# errorlog = '/var/log/prj/guni_prj_error.log' # simple logging to file
/etc/logrotate.d/supervisor
/var/log/supervisor/*.log {
missingok
rotate 60
daily
compress
delaycompress
notifempty
postrotate
/bin/kill -SIGUSR2 $(cat /var/run/supervisord.pid 2>/dev/null) 2>/dev/null
endscript
}
If you dont want use supervisord, gunicorn can write logs by it self (with standard logging)
Don't forget set "logconfig" option in gunicorn configuration
Logging config for example:
/opt/prj/gunicorn.log.conf
[loggers]
keys=root, gunicorn.error, gunicorn.access
[handlers]
keys=console, error_file, access_file
[formatters]
keys=generic, access
[logger_root]
level=INFO
handlers=console
[logger_gunicorn.error]
level=INFO
handlers=error_file
propagate=0
qualname=gunicorn.error
[logger_gunicorn.access]
level=INFO
handlers=access_file
propagate=0
qualname=gunicorn.access
[handler_console]
class=StreamHandler
formatter=generic
args=(sys.stdout, sys.stderr, )
[handler_error_file]
class=logging.handlers.WatchedFileHandler
formatter=generic
args=('/var/log/prj/guni_prj_error.log',)
[handler_access_file]
class=logging.handlers.WatchedFileHandler
formatter=access
args=('/var/log/prj/guni_prj_access.log',)
[formatter_generic]
format=%(asctime)s [%(process)d] [%(levelname)s] %(message)s
datefmt=%Y-%m-%d %H:%M:%S
class=logging.Formatter
[formatter_access]
format=%(message)s
class=logging.Formatter
Labels:
django,
djangoproject,
gunicorn,
logrotate,
python,
python2,
supervisord,
wsgi
Wednesday, November 12, 2014
Python RESTful webservices with Python: Flask & Django solutions
Maximum results with minimum cost
- that’s ideal of all business and software development processes. How to get such a results in project with tight deadline and big performance expectations? Unfortunately there is no easy way: quality of software needs time and money, but .. choice of technologies, tools, solutions can be critical for product lifecycle. We can improve total time and cost of development and maintenance by choosing appropriate solutions.
The basis of effective software development is deep research and experience built on previous projects and also mistakes. In our firm we carry out systematic research of technologies dedicated web and mobile development. We create internal projects and test to detect potential problems. Today I wont to present you short review of verified RESTful solutions for Python which really speed up development time.
Technology research and benchmarks
The picture below presents a benchmark of peak JSON response per second for many technologies also Python. There are 3 Python approaches with the following results:
- Django-stripped (Django without context processors and middlewares) – 13 269 per sec
- Flask – 11 506 per sec
- Django – 7122 per sec
Labels:
api,
django,
django-rest-framework,
flask,
pgsql,
postgresql,
python,
rest,
software,
web application
Friday, August 8, 2014
Swap usage by PID
#> for i in `find /proc -maxdepth 1 -type d|xargs -i basename {}`; do echo -n "PID: $i SWAP: "; cat /proc/$i/smaps|fgrep Swap|awk '{s=s+$2}END{print s}'; done|sort -k4n
Subscribe to:
Posts (Atom)