Tag Archives: General

Using CodePipeline to Host a Static Website

Post Syndicated from Jessica Veljanovska original https://www.anchor.com.au/blog/2022/10/using-codepipeline-to-host-a-static-website/

There are a variety of ways in which to host a website online. This blog (post) explores how to simply publish and automate a statically built website. Hugo is one such example of a system which can create static websites and is popularly used for blogs.

The final website itself, will consist and contain; HTML, CSS, Images and JavaScript. During this process, (Anchor’s cloud experts) have listed the AWS Services in order to achieve our goal. These include:

  • Cloudfront
  • CodeBuild
  • CodePipeline
  • IAM
  • Amazon S3
  • CodeCommit

This Solution should be well below $5 per month as most of the items are within the Always Free Tier, except the AWS S3 Storage (Which only has valid free-tier for the first 12 month) depending on the traffic.   

In order to keep this simple, the below steps are done via the console, although I have also published a similar simplified project using Terraform which can be found on Github. 

Setup the AWS Components
Setup S3 

To begin with, you will need to setup some storage for the website’s content, as well as the pipeline’s artifacts. 

Create the bucket for your Pipeline Files. Ensure that Block all public access is checked. It’s recommended you also enable Server-side encryption by default with SSE-S3. 

Create a bucket for your Website Files. Ensure that block all public access is NOT checked. This bucket will be open to the world as it will need to be configured to host a website. 

 

When the Website Files bucket is created. Go to Properties tab and Edit Static website hosting. Set it to Enable, and select the type as Host a static website. Save Changes. Note the URL under Bucket website endpoint.Go to Permissions tab and Edit the Bucket policy. Paste in a policy such as the sample below. Update ${website-bucket-name} accordingly to match the name of the bucket. 

<{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${website-bucket-name}/*" } ] } >

 

Setup IAM Users

You will need to first create an IAM Role which your CodePipeline and CodeBuild will be able to assume. Some of the below permissions can be drilled down further, as they are fairly generic. In this case we are merging the CodePipeline/CodeBuild into one user.  Create a Role in IAM with a unique name based on your project. You will need to setup the below trust policy.  


<{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "codebuild.amazonaws.com", "codepipeline.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } >

Create a Policy. Paste in a policy such as the below sample. Update ${website-bucket-name} and ${pipeline-bucket-name} accordingly. Attach the policy to the role you created in the step prior. 


<{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::${pipeline-bucket-name}/*", "arn:aws:s3:::${pipeline-bucket-name}", "arn:aws:s3:::${website-bucket-name}/*", "arn:aws:s3:::${website-bucket-name}" ] }>,

<{ "Sid": "", "Effect": "Allow", "Action": [ "codebuild:*", "codecommit:*", "cloudfront:CreateInvalidation" ], "Resource": "*" }>,

< { "Sid": "", "Effect": "Allow", "Action": [ "logs:Put*", "logs:FilterLogEvents", "logs:Create*" ], "Resource": "*" } ] } >

Setup CloudFront

  • Access Cloudfront and select Create distribution.
    Under Origin domain – select the S3 Bucket you created earlier.
  • Under Viewer protocol policy, set your desired actions. If you have a proper SSL you can set it up later and use Redirect HTTP to HTTPS.
  • Under Allowed HTTP methods, select GET, HEAD.
  • You can setup Alternate domain name here, but make sure you have an ACM Certificate to cover it, and setup Customer SSL certificate if you wish to use HTTPS.
  • Set the Default root object to index.html. This will ensure it loads the website if someone visits the root of the domain.
  • Leave everything else as default for the moment and click Create distribution.
  • Note down the Distribution ID, as you will need it for the Pipeline.

Setup the Pipeline

Now that all the components have been created, let’s setup the Pipeline to Tie them all Together.
Setup CodeCommit 
Navigate in to CodeCommit, and select Create Repository
You can use git-remote-codecommit in order to checkout the repository locally. You will need to check it out to make additional changes.  

You will need to make a sample commit, so create a directory called public and a file called index.html within it with some sample content, and push it up. 

$ cat public/index.html 
This is an S3-hosted website test 

After this is done, you should have a branch called “master” or “main” depending on your local configuration. This will need to be referenced during pipeline creation.
Setup buildspec in Repository 

Add a buildSpec.yml file to the CodeCommit Repo in order to automatically upload your files to AWS S3, and Invalidate the Cloudfront Cache. Note that ${bucketname} and ${cloudfront_id} in the examples below need to be replaced with the real values.  


version: 0.2

phases: 

  install: 

    commands: 

      - aws s3 sync ./public/ s3://${bucketname}/ 

      - aws cloudfront create-invalidation --distribution-id ${cloudfront_id} --paths "/*" 

Setup CodePipeline 

In our example, we’re going to use a very simple and straightforward pipeline. It will have a Source and Deployment phase. 

Navigate in to CodePipeline, and select Create Pipeline. Enter your Pipeline name, and select the role you created earlier under Service role. 

Under Advanced Settings, set the Artifact Store to Custom Location and update the field to reference the pipeline bucket you created earlier on. 

Click next, and move to Adding a Source Provider. Select the Source provider, Repository name and Branch name setup previously, and click next leaving everything else as default. 

On the Build section, select Build provider as AWS CodeBuild, and click Create Project under Project name.  

This will open a new window. Codebuild will need to be created through this interface, otherwise it doesn’t support the artifacts, and source configuration correctly. 

Under Environment, select the latest Ubuntu Runtime for codebuild, and under Service role select the IAM role you created earlier. Once that’s all done, click Continue to CodePipeline and it will close out the window and your project will now be created. 

Click Next, and then Skip deploy stage (we’re doing it during the build stage!). Finally, click on create the pipeline and it will start running based on the work you’ve done so far.  

The website so far should now be available in the browser! Any further changes to the CodeCommit repository will result in the website being updated on S3 within minutes! 

The post Using CodePipeline to Host a Static Website appeared first on Anchor | Cloud Engineering Services.

2022-10-15 Лекция от OpenFest 2022, “Голям monitoring”

Post Syndicated from original https://vasil.ludost.net/blog/?p=3458

Това е подготвения текст за лекцията, доста се разминава с това, което
говорих, но би трябвало поне смисъла да е същия 🙂


Ще ви разкажа за една от основните ми задачи в последните 5 години.

Преди да започна в StorPool, monitoring-ът представляваше нещо, което
периодично се изпълняваше на всяка машина и пращаше mail, който не беше съвсем
лесен за разбиране – нямаше начин да се види едно обща картина. За да мога да
се ориентирам, сглобих нещо, което да ми помогне да виждам какво се случва.
Лекцията разказва за крайния резултат.

Ще го повторя няколко пъти, но няма нищо особено специално, магическо или ново
в цялата лекция. Правя това от няколко години, и честно казано, не мислех, че
има смисъл от подобна лекция, понеже не показва нещо ново – не съм направил откритие
или нещо невероятно.

Имаше учудващо голям интерес към лекцията, за това в крайна сметка реших да я
направя.

Та, как пред ръководството да оправдаем хабенето на ресурси за подобна система
и да обясним, че правим нещо смислено, а не се занимаваме с глупости?

Ако нещо не се следи, не работи. Това е от типа “очевидни истини”, и е малка
вариация на максима от нашия development екип, които казват “ако нещо не е
тествано, значи не работи”. Това го доказваме всеки път, когато се напише нов
вид проверка, и тя изведнъж открие проблем в прилична част от всички
съществуващи deployment-и. (наскоро написахме една, която светна само на 4
места, и известно време проверявахме дали няма някаква грешка в нея)

Monitoring-ът като цяло е от основните инструменти за постигане на situational
awareness.

На кратко, situational awareness е “да знаеш какво се случва”. Това е различно
от стандартното “предполагам, че знам какво се случва”, което много хора правят
и което най-хубаво се вижда в “рестартирай, и ще се оправи”. Ако не знаеш къде
е проблема и действаш на сляпо, дори за малко да изчезне, това на практика нищо
не значи.

Та е много важно да сме наясно какво се случва. И по време на нормална работа,
и докато правим проблеми, т.е. промени – важно е да имаме идея какво става.
Много е полезно да гледаме логовете докато правим промени, но monitoring-а може
да ни даде една много по-пълна и ясна картина.

Да правиш нещо и изведнъж да ти светне alert е супер полезно.

(По темата за situational awareness и колко е важно да знаеш какво се случва и
какви са последствията от действията ти мога да направя отделна лекция…

А всичко, което забързва процеса на откриване на проблем и съответно решаването
му, както и всяко средство, което дава възможност да се изследват събития и
проблеми води до това системите да имат по-нисък downtime. А да си кажа, не
знам някой да обича downtime.

Да започнем с малко базови неща, които трябва да обясня, като говоря за monitoring.

Едното от нещата, които се събират и се използват за наблюдаване на системи са
т.нар. метрики. Това са данни за миналото състояние на системата – може да си
ги представите най-лесно като нещата, които се визуализират с grafana.
Най-честата им употреба е и точно такава, да се разглеждат и да се изследва
проблем, който се е случил в миналото (или пък да се генерират красиви картинки
колко хубаво ви работи системата, което маркетинга много обича).

Друго нещо, за което са много полезни (понякога заедно с малко статистически
софтуер) е да се изследват промени в поведението или как определена промяна е
повлияла. Това до колкото знам му казват да сте “data driven”, т.е. като
правите нещо, да гледате дали данните казват, че сте постигнали това, което
искате.

Метриките, които аз събирам са веднъж в секунда, за много различни компоненти
на системата – дискове, процесори, наши процеси, мрежови интерфейси. В момента
са няколко-стотин хиляди точки в секунда, и тук съм показал една примерна –
показва данните за една секунда за един процесор на една машина, заедно с малко
тагове (че например процесорът не се използва от storage системата, та за това
там пише “nosp”) и с timestamp.

Метриките са нещо, което не искаме да се изгуби по пътя или по някаква друга
причина, защото иначе може да се окаже, че не можем да разберем какво се е
случило в даден момент в системата. В някакъв вид те са като “логове”.

Метриките се събират веднъж в секунда, защото всичко друго не е достатъчно ясно
и може да изкриви информацията. Най-простия пример, който имам е как събитие,
което се случва веднъж в минута не може да бъде забелязано като отделно такова
на нищо, което не събира метрики поне веднъж на 10 секунди.

Също така, събития, които траят по секунда-две може да имат сериозно отражение
в/у потребителското усещане за работа на системата, което пак да трябва да е
нещо, което да трябва да се изследва. В 1-секундните метрики събитието може да
е се е “размазало” достатъчно, че да не е видимо и да е в границите на
статистическата грешка.

Имам любим пример, с cron, който работеше на една секунда и питаше един RAID
контролер “работи ли ти батерията?”. Това караше контролера да блокира всички
операции, докато провери и отговори, и на минутните графики имаше повишение на
латентността на операциите (примерно) от 200 на 270 микросекунди, и никой не
можеше да си обясни защо. На секундните си личеше, точно на началото на всяка
минута, един голям пик, който много бързо ни обясни какво става.

(отказвам да коментирам защо проверката на статуса на батерията или каквото и
да е, което питаме контролера отвисява нещата, най-вече защото не знам къде
живеят авторите на firmware)

Та това се налага да го обяснявам от време на време, и да се дразня на системи
като Prometheus, където практически по-добра от 3-секундна резолюция не може да
се постигне.

Също така, не знам дали мога да обясня колко е готино да пускате тестове, да
сте оставили една grafana да refresh-ва веднъж в секунда и почти в реално време
да може да виждате и да показвате на хората как влияят (или не) разлини
действия на системата, от типа на “тук заклахме половината мрежа и почти не се
усети”.

Другото нещо, което се следи е текущото състояние на системата. Това е нещото,
от което се смята статуса на системата в nagios, icinga и други, и от което се
казва “тук това не работи”. Системите, които получават тази информация решават
какви проблеми има, кого и дали да известят и всякакви такива неща.

Статусът е нещо по-общо, и май нямам пример, който мога да събера на един слайд
и да може да се разбере нещо. Много често той носи допълнителна информация,
от която може да дойде нещо друго, например “мрежовата карта е с еди-коя-си
версия на firmware”, от което да решим, че там има известен проблем и да
показваме алармата по различен начин.

Метриките са доста по-ясни като формат, вид и употреба – имат измерение във
времето и ясни, числови параметри. Останалите данни рядко са толкова прости и
през повечето време съдържат много повече и различна информация, която не
винаги може да се представи по този начин.

Един пример, който мога да дам и който ми отне някакво време за писане беше
нещо, което разпознава дали дадени интерфейси са свързани на правилните места.
За целта събирах LLDP от всички сървъри, и после проверявах дали всички са
свързани по същия начин към същите switch-ове. Този тип информация сигурно може
да се направи във вид на метрики, но единствено ще стане по-труден за употреба,
вместо да има някаква полза.

А какъв е проблема с цялата тази работа, не е ли отдавна решен, може да се питате…

Като за начало, ако не се постараете, данните ви няма да стигнат до вас. Без
буфериране в изпращащата страна, без използване на резервни пътища и други
такива, ще губите достатъчна част от изпращаните си данни, че да имате дупки в
покритието и неяснота какво се случва/се е случило.

Данните са доста. Написал съм едни приблизителни числа, колкото да си проличи
генералния обем на данните, налагат се някакви трикове, така че да не ви удави,
и определено да имате достатъчно място и bandwidth за тях.

Дори като bandwidth не са малко, и хубавото на това, че имаме контрол в/у двете
страни, e че можем да си ги компресираме, и да смъкнем около 5 пъти трафика.
За това ни помага и че изпращаните данни са текстови, CSV или JSON – и двете
доста се поддават на компресия.

Няма някой друг service при нас, който да ползва сравнимо количество internet
bandwidth, дори някакви mirror-и 🙂

Идващите данни трябва да се съхраняват за някакво време. Добре, че фирмата
се занимава със storage, та ми е по-лесно да си поискам хардуер за целта…

За да можем все пак да съберем всичко, пазим само 2 дни секундни данни и 1
година минутни. InfluxDB се справя прилично добре да ги компресира – мисля, че
в момента пазим общо около двайсетина TB данни само за метрики. За
monitoring данните за debug цели държим пращаните от последните 10 часа, но
това като цяло е лесно разширимо, ако реша да му дам още място, за момента
се събират в около 1.6TiB.
(Това е и една от малкото ми употреби на btrfs, защото изглежда като
единствената достъпна файлова система с компресия… )

Ако погледнем още един път числата обаче, тук няма нищо толкова голямо, че да
не е постижимо в почти “домашни” условия. Гигабит интернет има откъде да си
намерите, терабайтите storage дори на ssd/nvme вече не са толкова
скъпи, и скорошните сървърни процесори на AMD/Intel като цяло могат да вършат
спокойно тая работа. Та това е към обясненията “всъщност, всеки може да си го
направи” 🙂

Системите, които наблюдаваме са дистрибутирани, shared-nothing, съответно
сравнително сложни и проверката дали нещо е проблем често включва “сметка” от
няколко парчета данни. Като сравнително прост пример за някаква базова проверка
– ако липсва даден диск, е проблем, но само ако не сме казали изрично да бъде
изваден (флаг при диска) или ако се използва (т.е. присъства в едни определени
списъци). Подобни неща в нормална monitoring система са сложни за описване и
биха изисквали език за целта.

Имаме и случаи, в които трябва да се прави някаква проверка на база няколко
различни системи, например такива, които регулярно си изпращат данни – дали
това, което едната страна очаква, го има от другата. Понякога отсрещните страни
може да са няколко 🙂

Статусът се изпраща веднъж в минута, и е добре да може да се обработи
достатъчно бързо, че да не се натрупва опашка от статуси на същата система.
Това значи, че monitoring-ът някакси трябва да успява да сдъвче данните
достатъчно бързо и да даде резултат, който да бъде гледан от хора.

Това има значение и за колко бързо успяваме да реагираме на проблеми, защото
все пак да се реагира трябва трябва да има на какво 🙂

И имаме нужда тази система да е една и централизирана, за можем да следим
стотиците системи на едно място. Да гледаш 100 различни места е много трудно и
на практика загубена кауза. Да не говорим колко трудно се оправдава да се сложи
по една система при всеки deployment само за тази цел.

Това има и други предимства, че ако наблюдаваните системи просто изпращат данни
и ние централно ги дъвчем, промяна в логиката и добавяне на нов вид проверка
става много по-лесно. Дори в модерните времена, в които deployment-а на хиляда
машини може да е сравнително бърз, пак трудно може да се сравнява с един локален
update.

И това трябва да работи, защото без него сме слепи и не знаем какво се случва,
не го знаят и клиентите ни, които ползват нашия monitoring. Усещането е като
донякъде да стоиш в тъмна стая и да чакаш да те ударят по главата…

От какво е сглобена текущата ни система?

За база на системата използвам icinga2. В нея се наливат конфигурации, статуси
и тя решава какви аларми да прати и поддържа статус какво е състоянието в
момента.

Беше upgrade-ната от icinga1, която на около 40% от текущото натоварване умря и
се наложи спешна миграция.

InfluxDB, по времето, в което започвах да пиша системата беше най-свястната от
всичките съществуващи time series бази.

Като изключим доста осакатения език за заявки (който се прави на SQL, но е
много далеч и е пълен със странни ограничения), и че не трябва да се приема за
истинска база (много глезотии на mysql/pgsql ги няма), InfluxDB се справя добре
в последните си версии и не може да бъде crash-ната с някоя заявка от
документацията. Основното нещо, което ми се наложи да правя беше да прескоча
вътрешния механизъм за агрегиране на данни и да си напиша мой (който не помня
дали release-нахме), който да може да върши същото нещо паралелно и с още малко
логика, която ми трябваше.

От някакво време има и версия 2, която обаче е променила достатъчно неща, че да
не мога още да планирам миграция до нея.

Както обясних, проверките по принцип са не-елементарни (трудно ми е да кажа
сложни) и логиката за тях е изнесена извън icinga.

В момента има около 10k реда код, понеже се добавиха всякакви глезотии и
интересни функционалности (човек като има много данни, все им намира
приложение), но началната версия за базови неща беше около 600 реда код, с
всичко базово. Не мисля, че отне повече от няколко дни да се сглоби и да се
види, че може да върши работа.


Ако ползвате стандартен метод за активни проверки (нещо да се свързва до
отсрещната страна, да задава въпрос и от това да дава резултат), никога няма да
стигнете хиляди в секунда без сериозно клъстериране и ползване много повече
ресурси.

Дори и да не ползвате стандартните методи, пак по-старите версии на icinga не
се справят с толкова натоварване. При нас преди няколко години надминахме
лимита на icinga1 и изборът беше м/у миграция или клъстериране. Миграцията се
оказа по-лесна (и даде някакви нови хубави функционалност, да не говорим, че се
ползваше вече софтуер от тоя век).

Основният проблем е архитектурен, старата icinga е един процес, който прави
всичко и се бави на всякакви неща, като комуникация с други процеси,
писане/четене от диска, и колкото и бърза да ни е системата, просто не може да
навакса при около 20-30к съществуващи услуги и няколко-стотин статуса в
секунда. А като му дадеш да reload-не конфигурацията, и съвсем клякаше.

Изобщо, технически това един бивш колега го описваше като “десет литра лайна
в пет литра кофа”.

Новата например reload-ва в отделен процес, който не пречи на главния.

Признавам си, не обичам Prometheus. Работи само на pull, т.е. трябва да може да
се свързва до всичките си крайни станции, и като го пуснахме за вътрешни цели с
около 100-200 машини, почна да му става сравнително тежко при проверка на 3
секунди. Също така изобщо няма идеята да се справя с проблеми на internet-а,
като просто интерполира какво се е случило в периода, в който не е имал
свързаност.

Върши работа за някакви неща, но определен е далеч от нашия случай. Според мен
е и далеч от реалността и единствената причина да се ползва толкова е многото
натрупани готови неща под формата на grafana dashboard-и и exporter-и.


Компонентите са в общи лини ясни:

Агентите събират информация и се стараят да ни я пратят;

Получателите я взимат, анализират, записват и т.н.;

Анализаторите дъвчат събраната информация и на база на нея добавят още
проверки.

Тук не измислих как да го покажа, но това е един thread, който събира данни (от
няколко такива), и има един който изпраща данните и се старае да стигнат. Пак е
сравнително малко код и може да бъде сглобен почти от всеки.

За данни, за които повече бързаме да получим и не буферираме, има друг
интересен трик – да имате няколко входни точки (при нас освен нашия си интернет
имаме един “домашен”, който да работи дори да стане някакво бедствие с
останалия), съответно агентът се опитва да се свърже едновременно с няколко
места и което първо отговори, получава данните.

Понеже това е писано на perl по исторически причини, беше малко странно да се
направи (понеже select/poll на perl, non-blocking връзки и подобни неща не са
съвсем стандартни), но сега мога да го похваля, че работи много добре и се
справя вкл. и с IPv6 свързаност.

И всичкия код, който получава/прави анализи си е тип ETL
(extract-transform-load). Взима едни данни, дъвче, качва обратно.

В нашия случай това, което връща са състояния и конфигурации (ще го покажа
по-долу).

И един елементарен пример, почти директно от кода – обикаля данните за набор от
машини, проверява дали в тях има нещо определено (kernel, за който нямаме
качена поддръжка) и го отбелязва.

Има и по-интересни такива неща (анализи на латентности от метриките, например),
но нямаше да са добър пример за тук 🙂

“Липсата на сигнал е сигнал” – можем да знаем, че нещо цялостно или част от
него не ни говори, понеже имаме контрол в/у агентите и кода им, и знаем
кога/как трябва да се държат.

Някой би казал, че това се постига по-добре с активна проверка (“тия хора
пингват ли се?”), но това се оказва много сложно да се прави надеждно, през
интернета и хилядите firewall-и по пътя. Също така, не може да се очаква
интернета на всички да работи добре през цялото време (заради което и всичките
агенти са направени да се борят с това).

Както казах по-рано, Интернета не работи 🙂

Един от най-важните моменти в подобна система е колко работа изисква за
рутинните си операции. Понеже аз съм мързел и не обичам да се занимавам с
описване на всяка промяна, системата автоматично се конфигурира на база на
пристигналите данни, решава какви системи следи, какви услуги, вижда дали нещо
е изчезнало и т.н. и като цяло работи съвсем сама без нужда от пипане.

Има функционалност за специфична конфигурация за клиент, която изисква ръчна
намеса, както и изтриването на цялостни системи от monitoring-а, но това като
цяло са доста редки случаи.

Системата се грижи всичко останало да се случва съвсем само.

Това, което според мен е най-важното за тази и подобни системи – няма нищо
особено сложно в тях, и всеки, който се нуждае от нещо такова може да си го
сглоби. Първоначалната ми версия е била около 600 реда код, и дори в момента в
10-те хиляди реда човек може да се ориентира сравнително лесно и да добави
нещо, ако му се наложи.

Като пример, дори python програмистите при нас, които считат, че php-то трябва
да се забрани със закон, са успявали да си добавят функционалност там
сравнително лесно и със съвсем малко корекции по стила от моя страна.

Самото php се оказва много удобно за подобни цели, основно защото успява да се
справи и с объркани данни (което се случва при разни ситуации) и не убива
всичко, а си се оплаква и свършва повечето работа. Разбира се, това не е
единствения подходящ език, аз лично писах на него, защото ми беше лесен – но
ако искате да сглобите нещо, в наши дни може да го направите почти на каквото и
си искате и да работи. Python и js са някакви основни кандидати (като езици,
дето хората знаят по принцип), само не препоръчвам shell и C 🙂

Така че, ако ви трябва нещо такова – с по-сложна логика, да издържа повече
натоварване, да прави неща, дето ги няма в други системи – не е особено сложно
да го сглобите и да тръгне, нещо минимално се сглабя за няколко дни, а се
изплаща супер бързо 🙂

Monitoring системата се налага да се следи, разбира се. Всичкият софтуер се
чупи, този, който аз съм правил – още повече. По случая други колеги направиха
нещо, което да следи всичките ни вътрешни физически и виртуални машини, и това
между другото следи и големия monitoring 🙂

Изглежда по коренно различен начин – използва Prometheus, Alertmanager и за
база VictoriaMetrics, което в общи линии значи, че двете системи рядко имат
същите видове проблеми. Също така и допълнителния опит с Prometheus ми показа,
че определено е не е бил верния избор за другата система 🙂

Може би най-големият проблем, който съм имал е да обясня какво значи текста на
дадена аларма на други колеги. Тук например съм казал “има малък проблем (за
това е WARNING), в услугата bridge, има един счупен, нула игнорирани (по разни
причини) и 2 общо, и този на машина 4 е down” – и това поне трима различни
човека са ми казвали, че не се разбира. Последното ми решение на проблема е да
карам да ми дадат как очакват да изглежда и да го пренаписвам. От една страна,
съобщенията станаха по-дълги, от друга – не само аз ги разбирам 🙂

Няколко пъти се е случвало системата да изпрати notification на много хора по
различни причини – или грешка в някоя аларма, или просто има проблем на много
места. Като цяло първото може доста да стресне хората, съответно вече (със
съвсем малко принуда) има няколко staging среди, които получават всички
production данни и в които може да се види какво ще светне, преди да е стигнало
до хора, които трябва да му обръщат внимание.

Изобщо, ако човек може да си го позволи, най-доброто тестване е с production
данните.

Основна задача за всяка такава система трябва да е да се намалят алармите до
минимум. Би трябвало фалшивите да са минимален брой (ако може нула), а едно
събитие да генерира малко и информативни такива. Също така, трябва да има лесен
механизъм за “умълчаване” на някаква част от алармите, когато нещо е очаквано.

Това е може би най-сложната задача, понеже да се прецени кога нещо е проблем и
кога не е изисква анализ и познаване на системата, понякога в дълбини, в които
никой не е навлизал.

Решението тук е да се вземат алармите за един ден, и да се види кое от тях е
безсмислено и кое може да се махне за сметка на нещо друго, след което мноооого
внимателно да се провери, че това няма да скрие истински проблем, вероятно с
гледане на всички останали задействания на неприемливото съобщение. Което е
бавна, неблагодарна и тежка работа 🙂

Не исках да слагам този slide в началото, че сигурно нямаше да остане никой да
слуша лекцията. Оставям го да говори сам за себе си:)

OpenFest 2022 призиви

Post Syndicated from original https://vasil.ludost.net/blog/?p=3454

Добрутро.

Ще има пак OpenFest, 20-то издание, пак в София Тех Парк.
Изданието е юбилейно (поне в десетичната бройна система), та събираме желаещи да говорят, да правят работилници (т.е. workshop-и), както и да помагат. Както обикновено, записването е на cfp.openfest.org, срокът за лекции и т.н. е до 1.09.2022.

Чакаме с нетърпение 🙂

2022-03-07 война

Post Syndicated from original https://vasil.ludost.net/blog/?p=3453

От няколко дни си мисля колко много не искам да пиша тоя post.

За всички, които са живели под камък – преди 12 дни Русия нападна Украйна. Последиците от това безумие ще ги усещаме дълго време…

Да започна с краткото описание на руската пропаганда – мисля, че обяснява повечето лъжи, разпространявани по темата. Особено много ме дразни обяснението, че Путолини (някои хора ползват “Путлер”, ама определено се справя по-зле с blitzkrieg-а) нямал избор. Винаги има избор, и можеше вместо 30 години да си крадат усилено страната, да направят нещо смислено…

А вместо това някаква част от окрадените пари отидоха за информационна война. Която, да не се лъжем, в общи линии губехме. Достатъчно е да видим огромното одобрение за Путолини в България, всякаквото плюене против LGBT и ваксините и крайния ефект от това (най-слабо ваксинираната държава, най-голяма смъртност на глава от населението от COVID-19).
Колкото до свързаността на по-горните, много добре си личи кой започна да се изказва в подкрепа на войната, след като започнаха да режат различните източници на пропаганда. Дори и в нашите медии си личи, въпреки че доста от тях сериозно се уплашиха и леко промениха линията.
(няма да коментирам “националистите” предатели в парламента като Копейкин)

… а нас ни чака още една Северна Корея, само че по-близо до нас, и в която има наши близки. В момента самата Русия се опитва да се изолира от света, като се кани да се отреже от глобалния интернет (малко информация по темата), не могат да се случват разплащания (което се спира и от двете страни) и със спирането на полетите пък самите руснаци, които искат да се махнат от там, не могат. И докато там хората ще страдат заради изперкалия си “водач”, Европа (и в това число България) ще трябва да преосмисли зависимостите си и кой ни ги насади, и да направи нещо по въпроса.
(поне има сериозен шанс да намалее много влиянието на Русия в нашата политика и като цяло тяхната пропаганда, като не могат да плащат)

Но, в крайна сметка има значение какво правим, не какво говорим. Супер се радвам как доброволците от OpenFest почти моментално се навиха/захванаха да помагат за бежанците, и как се задвижиха организациите по темата. Не настигаме Полша, и не сме толкова желана дестинация (най-вече заради високия рейтинг на Путолини и като цяло голямото руско влияние тук), но все пак до преди няколко дни са пристигнали 20000 бежанци, и ще идват още. Можем да им помогнем, можем да помогнем на организациите, можем да спрем да купуваме руски газ най-накрая, и да измъкнем и хората от Русия/Беларус, останали там под управлението на малоумници.

Можем още неща, давайте предложения.

А аз ще се опитам да не си представям всеки път като си играя с децата какво ли се случва с децата в Украйна.

(защото може да не сме в списъка на следващите за нападане, но определено сме в списъка на по-следващите)

2021-12-29 равносметъчно

Post Syndicated from original https://vasil.ludost.net/blog/?p=3452

Някаква равносметка.

(чудех се дали да го пусна догодина, че да имам поне един post за тогава, но сега имам малко време)

Та, поред на случките:

– Случихме online FOSDEM (и догодина пак ще е online);
– Случихме един малък OpenFest в парка, присъствено, да се видят разни хора, че се бяха забравили. Не умряхме от жега, и се получи прилично събитие. Огромното ми желание е догодина да случим истинското, в голяма зала, както си трябва, ама да видим;
– Успяхме да си вземем апартамент и да го ремонтираме дотолкова, че да се нанесем (има неща за довършване, ама доколкото знам това винаги си е така). Зверовете са много щастливи 🙂
– Лятото успях да изкарам една двойна пневмония, от която май още имам някакви последствия, но като цяло съм добре.
– Работата е as usual много, но си остава интересна. Продължаваме да си търсим хора (както и всички останали), ако на някой му е скучно, може да пише.

Годината мина като някой натоварен работен ден – от тоя тип, в който си правил толкова много неща, че накрая не може да се сетиш за нито едно. Кога почна, кога свърши, тотално не е ясно, ако не растяха децата, можеше да не се усетя, че нещо се е променило 🙂

Отказвам да имам очаквания за идващата година. Някои хора казват, че поне supply chain проблема може да почне да се пооправя към края ѝ, а дано.

2021-10-18 vivacom

Post Syndicated from original https://vasil.ludost.net/blog/?p=3451

Има неща, дето не трябва да ме учудват, но все пак успяват.

Днес по някое време ми спря Internet-а. По принцип ползвам Comnet София, които се отделиха от Comnet, и които в последствие бяха купени от Vivacom. След известно гледане видях, че в лога на pppd-то има съобщение “Neplatena smetka”.

Звъннах по телефона, където бях пренасочен към call центъра на Vivacom. След някакво чакане (над 10 минути, не ми се беше случвало скоро) и ходене по менюта стигнах до някакви хора, които да видят какво става. Оказа се, че последното ми плащане е изтекло на 15.10, и днес, на 18ти, са ми спрели услугата. Не бях получил известие от epay, защото явно тази част вече е спряна. Питайки как мога да го платя online ми казаха – не може, нямате още клиентски номер, трябва в магазин.

Отидох до близкия техен магазин, където ме намериха по ЕГН и ми обясниха, че мога да си платя за 6 месеца или 1 година. Обясних, че този договор винаги е бил месец по месец, и за мен няма особен смисъл да плащам толкова време, при условие, че до месец ще съм се изнесъл. Гледаха, мислиха, обадих се и на техния call center пак, и след половин час изводът си беше все тоя – те такава услуга нямат, няма начин. От друга страна, води се предплатена, няма прекратяване или каквото и да е друго и не им дължа нищо.
(явно и не трябва да връщам ONT-то, дето Comnet ми дадоха).

Та, теглих им една учтива майна, и ще карам седмица-две-три на 3G, докато се пренеса.

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

Още 2 числа за броя на хората в IT-то

Post Syndicated from original https://vasil.ludost.net/blog/?p=3449

Наскоро се сетих да питам пак НСИ за броя хора в IT-то (както бях питал преди 2 години), и числата за 2018та са:
Код 25 (всички в IT-то) – 44633;
Код 2522 (системни администратори) – 6850;

Растежът за 4 години е близо 50%…

OpenFest 2021 в парка

Post Syndicated from original https://vasil.ludost.net/blog/?p=3448

Ще се случва OpenFest 2021.

Ще е на открито, в “Маймунарника” в Борисовата градина, 14-15 август (стига да не се случи ОЩЕ нещо форсмажорно).

По случая – търсим лектори (особено за workshop-и) и както обикновено, набираме доброволци.

За пръв път организираме по този начин нещата, и въпреки че има да се решат всичките стандартни проблеми на ново място, събитието отсега се очертава да бъде забавно, и за присъствие, и за организиране 🙂

2021-06-06 разни

Post Syndicated from original https://vasil.ludost.net/blog/?p=3447

(каня се от известно време да напиша нещо за наемането на хора, но все не ми остава време. За това – събирателен post с някакви случили се неща)

Успях да изкарам двустранна пневмония. Не е ясно как съм я хванал – прояви се няколко дни след втората доза ваксиниране, COVID тестовете ми излизаха отрицателни, и освен да съм пипнал нещо на някоя опашка, не ми хрумва друг вариант. Изписаха ми два мощни антибиотика, пих ги две седмици и сега още се оправям, малко по малко.
(добре, че семейството преди това беше заминало в Бургас, и не трябваше да ме гледат и мен заедно с децата)

На рентгеновите снимки вече не се вижда проблем, на слушалка последния път се чуваше нещо (и след още няколко седмици пак ще ида да ме преслушат), а нивата ми на сатурация стоят на 97 (проверих специално апарата дали е добре, и при Елена показваше 99, та проблемът си е в мен явно), та ще се работи бавничко по възстановяването.

In other news, има колебание какво да се прави с OpenFest. Има една анкета на bit.ly/openairopenfest за дали да направим нещо на открито през лятото, има въпроса дали да се опитаме и нещо на закрито есента, но тотално го няма въпроса дали да направим чисто online събитие – по всичко, което чувам/усещам, на всички им е омръзнало. Най-хубавия цитат по темата ми е от преди няколко дни от един семинар на RIPE, в който някой каза “писнало ми е от zoom meeting-и, в които се оплакваме от zoom meeting-ите”.

Ако не сте попълнили анкетата и ви е интересен феста, напишете нещо. От наша страна ще има опит да съберем екип (понеже всички изглеждат адски уморени и не знам дали искам да им го причинявам), и се надявам до няколко седмици да има някаква яснота.

Също така, не е задължително да правим каквото и да е. Може просто да оставим хората да се събират по кръчмите/парковете, да се видят и малко по малко да работят по въпроса да не им трябват психотерапевти…

Navigating the Anchor Customer Portal

Post Syndicated from Hendrik Kruizinga original https://www.anchor.com.au/blog/2021/02/navigating-the-anchor-customer-portal/

The Anchor Customer Portal is a central spot for you to review your current service with us and update your account details.

Access:

Access to the portal will be provided when you are on-boarded as a customer. You will receive login credentials by email to reset/create your password and sign in. 

If you have forgotten your password, you can reset it here.

Updating your account details:

Within the customer portal you will be able to review and update your account information and billing details. You’ll also be able to manage your domains and DNS and purchase additional services.

Reviewing and logging support tickets:

Once you are logged in to the portal, you will be able to review a log of historic support tickets and any interactions between you and the customer support team.

You are able to submit a new ticket within the portal or can quickly and easily log a support ticket by emailing: [email protected]

 

AWS Managed Service Customers

If you are consuming an AWS service with Anchor, you will also have the following access within your customer portal.

Review your services and monthly spend:

Under the services tab you will see an overview of all your products and services with Anchor. When a product or service has been selected you will have the ability to see your account and billing information. 

You will also be able to see an overview of your historic monthly costs (past 12 months) and the breakdown of the products and services that make up your monthly cost. To allow you to easily forecast monthly spend, you also have visibility into your current and projected monthly figures.

If you are an existing customer and need any support or have any questions regarding the Anchor customer portal, please reach out to your account manager or log a ticket by emailing [email protected]

The post Navigating the Anchor Customer Portal appeared first on AWS Managed Services by Anchor.

AWS Managed Services by Anchor 2021-02-15 06:47:22

Post Syndicated from Andy Haine original https://www.anchor.com.au/blog/2021/02/25661/

How handy would a cool $5000 boost be to improving your company’s digital disaster plan? Amazon Web Services’ “Project Resilience” may be just the ticket to securing your organisation in the event of a future disaster.

AWS recently announced that they would be launching “Project Resilience” in Australia and New Zealand. With the Project Resilience initiative, local governments, community organisations, and educational institutions will be provided with up to $5,000 USD (roughly $6,500 AUD at time of writing) in account credits to assist them in preparing for the potential impacts caused by human errors or natural and manmade disasters. If your organisation is granted a credit, it will be valid for one year, or until it is fully used up. AWS has advised there will be no opportunity to extend the validity of any credit given, so it is important to plan out your project’s timeline if you intend to apply to ensure you do so at the right time.

In addition to the initial credit, a further ~$6,500 AUD credit may be provided towards the cost of hiring AWS Professional Services where necessary – however, organisations may still choose to seek their own support from a certified AWS partner.

Country Director Australia and New Zealand for Amazon Web Services Public Sector, Iain Rouse, had this to say:

“AWS Project Resilience supports organisations, such as those on the front lines including police, fire, and emergency responders, that play a critical role in ensuring their community’s resilience, by helping them develop and manage the technology-based aspects of disaster preparedness.”

“Project Resilience offers eligible local government, education, and small and medium community organisations up to US$5,000 in AWS credits, which can be used to offset the cost of storing their data safely and securely on AWS. This means that even if computing equipment, such as laptops and servers, are damaged in a disaster, their critical data is still securely stored in the AWS Cloud, and can be easily accessed by them at any time.”

As we know too well from the tumultuous summer we faced in 2019 through 2020, Australia is particularly susceptible to natural disasters, such as bushfires and flooding. New Zealand has also had their fair share of natural disasters in recent years in the form of earthquakes, cyclones and volcanic events. And of course, there is the current global disaster that is COVID-19. Rouse adds that “It is vital for AWS to work along with partners and customers to help people respond to such crises and develop solutions that’ll help reduce the impact of such disasters”.

The initiative is a great move to encourage organisations to move into new digital territories that can greatly enhance their efficiency and survivability with significantly improved data storage infrastructure, as well as more reliable disaster recovery and security processes. The reliability that AWS cloud provides is absolutely crucial when disasters and emergency services are involved. Having your important business data and assets safely stored and replicated across multiple geographical locations goes a long way to ensure a business can quickly recover from the unexpected. It seems Rouse would agree, saying that “One of the many critical tasks in times of a disaster is to make sure data regarding people, services and assets stay safe and accessible, even under threat”.

It’s an exciting time for Australia in the cloud space. Our geographical remoteness and the associated cost of bandwidth has often led to our exclusion, or at least, a significant delay when it comes to enjoying the latest in technological advancements. But times have largely changed in that regard in that our remote location is no longer such a hindering factor. And now, with AWS providing specialised support offerings to their customers based on their particular challenges, the benefits of cloud technologies are only growing.

AWS continues to innovate on their product offering, providing initiatives to their customers of all sizes, with Australia and New Zealand very much included. With Amazon late last year announcing they would be creating a new AWS region in Melbourne (their second region for Oceania), there has never been a better time to make the move to the cloud. (P.s. You can check out our blog post covering the new Melbourne AWS region here!)

While AWS have not mentioned many specifics regarding eligibility, an application form and further information regarding Project Resilience can be found on the AWS website here.

The post appeared first on AWS Managed Services by Anchor.

2021-01-26 работна среда

Post Syndicated from original https://vasil.ludost.net/blog/?p=3446

Писал съм преди за работната си среда, и понеже при нас във фирмата аз onboard-вам новите хора за оперативния екип, ми се налага да обяснявам как може да се работи по-ефективно (даже си направихме един вътрешен training, в който показвахме кой как работи). Понеже така и не записах моите обяснения, ще взема да ги напиша един път, с колкото мога подробности, може и да е полезно за някой.

В общи линии при работа вкъщи или в офиса нещата са ми по същия начин, въпреки че е малко криво логистично (и може да ми се наложи да си купя още един квадратен монитор в някакъв момент).

Хардуер

Ще започна с по-хардуерната част.

За стол ползвам от 10тина години един Markus от IKEA, и в последните две фирми убедих хората, че това е удобния стол. Издържа много, удобен е, и не е безумно скъп (не е и евтин, около 300 лв беше последно). Аз го ползвам без подлакътници (понеже така може да се пъхне повече под бюрото, като реша).

Гледам да имам достатъчно широко бюро, поне метър и половина. С двата монитора и двата лаптопа (за тях по-долу) си е нужно място, а и аз имам навика да трупам на него, и са известни случаи, в които съм завземал съседни бюра за някаква част от техниката, с която работя. По принцип е хубаво бюрото да е с дебел, здрав плот, та да не клати много (което се случва понякога при моето писане), но по-здравото ми бюро го ползва в момента Елена (на него пък не можех да си сложа стойките), и за това съм измислил допълнително укрепване на монитора.

От StorPool открих идеята със стойките за монитори – ползвам две Arctic Z1 Basic. Дават ми възможност да си подредя мониторите точно както искам, и освобождават място на бюрото, в което може да се озоват други неща (напр. разклонители).

Сравнително скорошна снимка (с грешната клавиатура)

Много години си имах нормален настолен компютър, после минах на лаптоп, и в момента съм на “компромиса” да съм с лаптоп, който да ползвам на практика като работна станция (не съм го отварял от 3 месеца, само си стои и скърца). В момента е T70 дъно (което правят едни китайски ентусиасти от 51nb.com) в T60p лаптопска кутия, която отне един ден флексотерапия за монтажа. Взех си го заради 4:3 монитора и възможността да имам прилично бърз лаптоп (вече съм му сложил 32GB памет, щото 16 не стигаха), с поносима клавиатура – след Tx20 серията lenovo почнаха да слагат още по-гадни клавиатури, а да стоя на T420 почваше да става бавно и мъчително (и да свършват лаптопите).
Ако тръгна да си вземам нов, вероятно няма да обърна внимание на тия подробности и ще гледам основно да му държи батерията и да не твърде малък екрана (и да не се чупи лесно, все пак се мотаят деца наоколо).
Около това минах и основно на жична мрежа, понеже няма смисъл да си тормозя wifi-то за нещо, което не разнасям.

Около пандемията и работата от вкъщи взех стария лаптоп на Елена и го ползвам за всичките видео/аудио конференции. Така мога да правя нещо и да мога да виждам с кого си говоря, и да не си товаря работния лаптоп с глупости.

За самите разговори имам два audio device-а – една Jabra speak за през повечето време и една jabra wireless слушалка за като трябва да съм по-тих (или да съм в съседната стая, докато върви разговора 🙂 ). Специално Jabra speak-а е наистина страхотно устройство, с много добро качество на звука и микрофона и почти невероятен echo cancellation, аз в крайна сметка съм купил поне 5-6 такива и съм давал на разни хора, на които им трябва. Силно препоръчвам – удобно е, чува се добре и не тормози ушите.

Мониторите са много интересна тема. Както казах по-горе, избирах си лаптоп специално с 4:3 екран, понеже 16:9 и 16:10 не ми стигат като вертикала, и най-накрая няколко приятели ми се ядосаха и ми купиха квадратен монитор (Eizo EV2730Q). Отне ми няколко дни да свикна с идеята, и от тогава насам не мога да си представя как живял без него – събира ми се всичко, имам място да си наслагам много прозорци, и като реша да пиша текст като този, мога да го отворя на цял екран на увеличен шрифт и да си пиша на воля. Като гледам, по-голям монитор от този вече ще ми е трудно да ползвам, но този мога да обхвана с поглед и половина и спокойно да гледам 2-3 лога как мърдат, докато работя по някаква система.
За лаптопа, който ползвам за видео конференции ползвам един 24″ монитор, който не е нещо особено (взех го евтино от ebay), целта му е да мога да виждам с кого говоря.

Клавиатурата е почти религиозна тема. След всякакви клавиатури, известно време ползване на IBM Model M и после дълги години лаптопски на Lenovo T серия, като минах на квадратния монитор си взех пак Model M-то. В офиса обаче вдигнаха бунт срещу мен (“не можем да си чуваме мислите, докато пишеш”) и като компромис си взех една Das Keyboard с кафеви switch-ове, която не е лоша, но … не е същото нещо. С пандемията можах пак да се върна на Model M-то (щото не се чува през стената да буди децата) и даже за нова година си взех една от новото производство на Unicomp (pckeyboard.com им е сайта). На цена, с доставката от САЩ ми се върза на същите пари като DasKeyboard-а.
Като усещане, за мен няма по-добра клавиатура, и дори се усещам как copy-paste-вам по-малко, понеже правя по-малко грешки, докато пиша. Единствения проблем на клавиатурата е шумът, но новата версия е малко по-басова и по-поносима за околните като звук (но ако се върнем в офис някой ден и трябва да съм с някой друг в стая, трябва или да е глух, или пак да сменя клавиатурата).

Снимка на старата и новата клавиатури

Като pointing device ползвам един безжичен logitech trackball – не ми се налага да си местя много ръката по бюрото, и поне на мен ми е удобно да си го ползвам с палеца. Налага се да го чистя от време на време (което не се случва особено много с модерните оптични мишки), но аз съм свикнал от едно време, и децата много се радват на голямото топче…

Софтуер

От около 22-23 години съм на Debian, и не съм намерил причина да го сменям. Имал съм периоди на ползване на пакети от Ubuntu, но като цяло си ги харесвам като дистрибуция – ползвам го за работни станции, сървъри и каквото ми се наложи и все още много му се радвам.

Отгоре има стандартен X, и в/у него XFCE с Compiz за window manager. Причината да ползвам Compiz е, че е най-бързо работещия window manager, който съм виждал, най-вече за нещата, които аз правя (например switch на workspace не примигва по никакъв начин). Дава много начини за настройка (което аз обичам, понеже мога да си го напасна до моите нужди).
Основните неща, които настройвам са:
– focus follows mouse, т.е. не трябва да click-на на прозорец, че да ми е на фокус и да работя в него – това много забързва нещата, и дава възможност да се пише в прозорец, който не е най-отгоре;
– 11 workspace-а (достъпни с ctrl-alt-1..-). Първо бяха 10, но не стигаха (те и сега не стигат, но ctrl-alt-= май е заето и е много близо до ctrl-alt-backspace:) );
– ползвам Desktop cube plugin-а за много workspace-и, и съм сложил скоростите на максимум, та на практика превключвам мигновено м/у два workspace-а.

За повечето си комуникация ползвам pidgin с кофа plugin-и за различните messenger-и. Имам едно-две irc-та, два jabber-а, два slack-а, skype, telegram, и вероятно още някакви неща. Pidgin-а е от софтуерите, за които си компилирам и дебъгвам някакви неща (ползвам го от пакет, едно време и си го компилирах сам). Повечето комуникация да ми е на едно място е доста удобно, щото не трябва да превключвам м/у 10 неща.
Понеже за някои неща поддръжката му не е много добра, ползвам и web версиите им – например фирмения Slack, понеже така ми излизат както трябва notification-ите, и от време на време този на Telegram (например като ми пратят контакт).

Ползвам и claws-mail за mail client, понеже имам много поща и не мога да понасям web-интерфейсите за поща. Ползвал съм преди evolution и малко съм пробвал thunderbird, но са ми бавни и неудобни, а claws-а се оправя много добре с десетки/стотици хиляди писма, pgp и т.н..

Ползвам и два browser-а – един chrome и един firefox – google docs и подобни неща работят много по-добре в chrome, а електрическия ми подпис само във firefox, и съм разделил някак кое къде ползвам. Двата browser-а са причината за 32-та GB памет, ядат много (и често развъртат вентилаторите).

Да следя какво правя ползвам gtimelog – много удобно приложение бързо да си отбелязваш какво си правил, и така следя горе-долу какво съм правил през деня, да имам някаква идея кога трябва да си стана от бюрото и да мога да кажа какво съм правил, ако някой ме пита (или аз се чудя).

И приложението, в което на практика живея – xfce4-terminal 🙂 Пробвал съм различни, но този е достатъчно бърз, и поддържа правилния вид прозрачност. Пуснал съм му голям scrollback, и съм сложил Go Mono шрифт (който е серифен, но по някаква причина ми е по-удобен от останалите). Нещо, което много ползвам и не препоръчвам на никой е прозрачността да гледам терминала под него, основно дали нещо мръдва (и което подлудява повечето хора, които ми гледат екрана).

За текстов редактор ползвам vim, на който не съм правил нищо специално, само за някои директории имам да прави git commit всеки път, като запише файл, много е удобно за файлове с бележки и подобни.

Процес на работа

Всичко това е навързано в моя леко странен начин на работа…

Използвам workspace-ите, за да си организирам различните задачи:
– Първия е за messenger, gtimelog и един vim с бележки;
– Втория е за пощата – claws-mail и някакво количество отворени mail-ове, на които трябва да отговоря (ако не ги отворя, няма начин да ги запомня);
– трети до осми са за терминали. Горе-долу workspace за задача, понякога два;
– девети за chrome, десети за firefox;
– последния за неща, дето почти не гледам, например vpn-а или контрола на музиката вкъщи.

Основният принцип, който гледам да следвам е всяко нещо, което ми трябва в дадена задача да е на един клавиш/комбинация разстояние. Например два терминала на един workspace, и като трябва, превключвам м/у тях. Ако ми трябват още, слагам ги на съседния workspace. Ако са някакви по-странни неща, слагам tmux и го деля на две (при моя монитор и хоризонталното, и вертикалното разделяне работят много добре).

Да си погледна messenger-а, ако има нещо светнало, ми е лесна комбинация, да си видя пощата пак, да отида до по-важните задачи (които гледам да държа на началните workspace-и) – също, директно с лява ръка. Ако трябва да ходя до browser-ите ми е малко по-бавно, но за там най-често така и така си трябва context switch в главата.

Нещо, което също много ми помага, понеже през голяма част от времето си пиша с хора е, че сменям кирилица/латиница с caps lock – един клавиш, на лесно място. Идеята с shift+alt винаги ми се е виждала ужасна, и много често задейства контекстните менюта някъде. Като добавка, ползвам kbdd за да помни в кой прозорец на какъв език съм бил, та да не се налага да превключвам постоянно, като се местя м/у комуникация и терминалите.

Разни

Има разни неща, които съм спрял да ползвам, щото са ми пролазили по нервите. Може би основното такова нещо е Gnome и повечето му неща – терминалът е бавен, windowmanager-а също, и основната работа на разработчиците му беше да премахват настройките, които ползвах. След като един път ми отне половин ден да убедя курсора ми да не мига (или някаква подобна глупост), минах на Xfce.

По същия начин зарязах evolution, понеже ядеше гигантски количества памет и ставаше все по-бавно и по-бавно. Claws-mail ми върши същата (и по-добра работа) с няколко пъти по-малко ресурси.

2021-01-17 post-hireheroes

Post Syndicated from original https://vasil.ludost.net/blog/?p=3445

(втори пост!)

Dev.bg имаха интересен проект, наречен “HireHeroes”. Идеята беше в общи линии някакво количество “герои” да могат да си говорят с потенциални кандидати, които искат да се ориентират по-добре какво да правят, и да могат да ги препоръчат в определени фирми.

Цялата идея имаше някакъв комерсиален момент, но за мен основната причина да се занимавам беше, че имах възможност да ориентирам и помогна на някакви хора (сравнително близо до моята област) какво могат да очакват, към какви неща да се насочат и т.н.. Това е нещо, което опитвахме/правихме и на срещи с ученици в initLab, но сега особено тия неща са умрели, а с моето семейно/работно разписание ми е малко трудно да отделя няколко часа да ходя някъде…

Та, dev.bg прекратиха HireHeroes (и направиха job board, който най-вероятно ще им е повече на печалба), но не мисля, че всичко от тая идея трябва да умре. Та, ако някой има нужда от съвет, идеи, иска да си сменя типа работа и изобщо въпроси по темата, съм щастлив да отговарям/помагам доколкото мога. Mail-а ми е като сайта ми, може да оставяте коментари в блога и т.н., а за който иска, успявам да изкопча по някой друг час на седмица за video call.

Hostopia Australia continues to build momentum into 2021 as Contino’s Gerald Bachlmayr is appointed as Chief Architect – AWS Cloud.

Post Syndicated from Andy Haine original https://www.anchor.com.au/blog/2021/01/gerald-bachlmayr-appointment/

14th January 2021 – Anchor is excited to welcome Gerald Bachlmayr as our Chief Architect – AWS Cloud.

The newly created role comes after a year of significant investment and growth into our AWS business and follows the appointment of new General Manager, Darryn McCoskery, in February 2019.

In his new role, Gerald is spearheading the AWS cloud and customer delivery strategy for Anchor, whilst streamlining the delivery for AWS cloud customers. 

Gerald is excited and energised for the journey ahead and looks forward to the new challenge and continuing to drive AWS momentum for Anchor.

“There is a strong movement towards digital transformation and simplification within the industry. This is a huge opportunity for Anchor to leverage our exemplary engineering talent and experience to deliver an outstanding customer experience”, Gerald said.

Prior to his two and a half year stint at Contino as Technical Principal Consultant, Bachlmayr held cloud transformation and consulting roles as Westpac Group, Transport for NSW and University of NSW.

As an AWS and digital transformation ambassador and with a long list of AWS certifications under his belt, Gerald’s appointment sets the scene for the growth to come for Anchor and AWS in 2021.

You can find a list of Bachlmayr’s previous publications here.

The post Hostopia Australia continues to build momentum into 2021 as Contino’s Gerald Bachlmayr is appointed as Chief Architect – AWS Cloud. appeared first on AWS Managed Services by Anchor.

2021-01-02 равносметъчно

Post Syndicated from original https://vasil.ludost.net/blog/?p=3444

За да докарам поне един post тая година (щото не е ясно дали ще намеря време за повече), ето една равносметка за миналата година:

– Оживяхме, и не карахме вируса;
– Малките зверове растат усилено и правят всякакви интересни и опасни открития;
– Жена ми още не ме е убила;
– Успяхме да случим FOSDEM преди големите заразявания и затваряния;
– За да успявам да работя и да съм около семейството, правихме всякакви странни неща – работа от вкъщи, от Бургас, пътувах си с цялата техника и т.н.. Много се разглезих с квадратния монитор и хубавата клавиатура, та пренасянията ми не са толкова прости 🙂 ;
– На практика цялото лято го изкарах в Бургас, ДОРИ ме заведоха няколко пъти на плаж (и спокойно мога да кажа, че все още не ми харесва) (и ми напомниха да спомена, че не съм си свалил кубинките на плажа);
– Годината като цяло показа, че работата от вкъщи поне за мен се получава. Допълнителен плюс е, че мога да си ползвам шумната Model M клавиатура без целия офис да иска да ме удуши (освен когато забравя да си mute-на микрофона);
– “Кривото” на ъгъла на “Дондуков” и “Будапеща” го закриха още преди пандемията, но ние пренесохме ИББ online на b.1h.cx (една BBB инстанция на машина на Мариян). Малко се промениха посетителите, но пък така успяваме да се видим с доста хора от други времеви зони и други места, та май си е плюс;
– От време на време успявах да се наспя, повечето време – не;
– Случи се OpenFest, online, в общи линии без мое участие. Супер горд съм с екипа 🙂

Селекция “офисни” снимки:
– Вкъщи 1;
– Бургас 1;
– Бургас в полеви условия;
– Вкъщи 2;
– Бургас 2;

За новата година… Очаквам да не е по-зле от изминалата, или поне се надявам 🙂 Определено чакам с нетърпение да видя колко карантинни бебета ще се появят.

И ето ни една обща снимка.

2020-11-15 обяд?

Post Syndicated from original https://vasil.ludost.net/blog/?p=3443

Пак се очертават lockdown-тип мерки, и като цяло хората са си орязали социалните контакти, някои са под карантина, други са директно заразени…

По темата, за по-малко полудяване на хората освен ИББ, което случваме online всяка сряда (и което в последно време не се пълни много), мислим да направим ОО (openfest обяд), всеки ден след 12:30 пак както ИББ на b.1h.cx, което си е една наша BBB инстанция с 4 “стаи”, в които може и да видите кой е. Така хората могат да имат компания за обяд извън стандартния си кръг познати 🙂

Това е и донякъде възраждане на идеята на IRC – място за събиране на хора, които не е задължително да се познават. Мисля си, че ако irc-то беше наполовина толкова използвано, колкото през 2000та, щеше рязко да се препълни, но сега както е непознато, хората си седят в балончетата във facebook и бавно се побъркват…

(Иначе, моето мижаво irc работи, който иска може да дойде на irc.ludost.net:6697 (SSL/TLS), #marla, или през webirc.ludost.net)

Та, ако ви е скучно по обяд (или сряда вечер след 19:00-19:30), b.1h.cx 🙂