Commit 76e9b480 authored by s1udge's avatar s1udge 💬

added changelog, copyright, fixed links, added outage post

parent a7d31829
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
### Summary
(Summarize the bug encountered concisely)
### Steps to reproduce
(How one can reproduce the issue - this is very important)
### System details
(list your hardware details and the version of Parrot OS, please include version, edition, and architecture)
(For x86_x64 systems: What method did you use to install Parrot? Debian Standard / Debian GTK / parrot-experimental)
(Configured to multiboot with other systems? yes / no)
### What is the current *bug* behavior?
(What actually happens)
### What is the expected *correct* behavior?
(What you should see instead)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)
### Output of checks
(If you are reporting a bug on, write: This bug happens on Nest. Otherwise describe where this bug occurs.)
## Possible fixes
(If you can, link to the line of code that might be responsible for the problem)
/label ~bug ~reproduced ~needs-investigation
/cc @palinuro
/assign @s1udge
### Problem to solve
<!-- What problem do we solve? -->
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas can be found at -->
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! -->
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow
Add all known Documentation Requirements here, per -->
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### Links / references
/label ~"feature request"
# README first!
This MR should be created on ``.
## Related issues
<!-- Mention the issue(s) this MR is related to -->
## Developer checklist
- [ ] Link to the developer security workflow issue on ``
- [ ] MR targets `master`, or `X-Y-stable` for backports
- [ ] Milestone is set for the version this MR applies to
- [ ] Title of this MR is the same as for all backports
- [ ] A [CHANGELOG entry]( is added without a `merge_request` value, with `type` set to `security`
- [ ] Add a link to this MR in the `links` section of related issue
- [ ] Assign to a reviewer (project maintainer)
## Reviewer checklist
- [ ] Correct milestone is applied and the title is matching across all backports
- [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines
/label ~security
<!-- Follow the documentation workflow -->
<!-- Additional information is located at -->
<!-- Mention "documentation" or "docs" in the MR title -->
<!-- For changing documentation location use the "Change documentation location" template -->
## What does this MR do?
<!-- Briefly describe what this MR is about. -->
## Related issues
<!-- Link related issues below. Insert the issue link or reference after the word "Closes" if merging this should automatically close it. -->
## Author's checklist
- [ ] Follow the [Documentation Guidelines]( and [Style Guide](
- [ ] Link docs to and from the higher-level index page, plus other related docs where helpful.
- [ ] Apply the ~Documentation label.
## Review checklist
All reviewers can help ensure accuracy, clarity, completeness, and adherence to the [Documentation Guidelines]( and [Style Guide](
**1. Primary Reviewer**
* [ ] Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
**2. Technical Writer**
* [ ] Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable [DevOps stage](
**3. Maintainer**
1. [ ] Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
1. [ ] Ensure a release milestone is set and that you merge the equivalent EE MR before the CE MR if both exist.
1. [ ] If there has not been a technical writer review, [create an issue for one using the Doc Review template](
/label ~Documentation
- Changelog added.
- favicon added.
- Copyright added to footer.
\ No newline at end of file
......@@ -29,7 +29,7 @@ _Please do not use the issue tracker for support questions, please post on the [
## Maintainers, response time and security issues.
**Primary:** Palinuro
**Primary:** Palinuro <br>
**Alternate:** Pino
You should get a response from a maintainer within **five days** for a merge request and **seven days** for everything else.
......@@ -74,4 +74,4 @@ DEPENDENCIES
......@@ -6,12 +6,116 @@ This is the offical blog and news source of the Parrot Project.
This blog was made with Jekyll as static HTML site.
These instructions will get you a copy of the blog on your machine so you can verify your adjustments won't break the site before you push or submit a merge request.
### Prerequisites
- ParrotOS or similar Debian-based x64 system
- Internet access
- `sudo` access
### Installing
As Jekyll depends on Ruby's Gems you will need to install the following
sudo apt-get install ruby-full build-essential
And add these to your bashrc
echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc
echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc
echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
Then install Jekyll via gem
gem install jekyll bundler
Now clone this project:
git clone
cd blog
And make a new branch in case you muck things up
git checkout -b NEW-BRANCH
Then initialize things:
bundle init
If you run into issues you may have an old version of bundle, try this:
bundle update --bundler
And now run bundle:
bundle install
bundle update
Now things are ready to make changes and test.
## Adding features or pages/posts and running tests
To make a new post
cd _posts
Then open whatever editor you want, fill in the the following and edit the post as needed:
(links starting with # are comments and should be erased before sending to nest)
id: 257
title: Parrot 4.6 release notes
# The title to show people.
date: 2019-04-26T09:32:40+00:00
# The date
author: Lorenzo "Palinuro" Faletra
# name of whoever is writing the post.
layout: post
# This should always be post
permalink: /parrot-4-6-release-notes/
# the link this post will have regardless of domain changes.
- release notes
#is it news or release notes
(see [here]( for more info on posts)
**To add a page see [here](**
After you've made your changes, written a post etc, you will want to save them and make sure they work.
To show things as you work run:
bundle exec jekyll serve
Which builds the blog to
and allows you to see your changes as you make them in your editor (it also shows in your terminal).
Verify that nothing breaks, before you continue.
### Git and version control
After making your changes ensure you sign, commit and merge them into dev, then push to nest.
## Built With
* [Jekyll]( - Jekyll Static Site Generator.
* [Open Source Guide]( Content based on []( used under the CC-BY-4.0 license.
* [Jekyll Docs]( portions of the above content are from Jekyll's documentation used under the MIT License.
## Contributing
......@@ -27,7 +131,7 @@ See also the list of [contributors]( who participated in this pr
## Licenses
This project is licensed under the GPLv3 and CC-BY-SA v4.0 Licenses - see the []( file for details.
This project is licensed under the GPLv3 and CC-BY-SA v4.0 Licenses - see the []( file for details.
## Acknowledgments
......@@ -16,8 +16,8 @@
name: Parrot Project Blog
description: ""
title: Parrot Project Blog
url: ""
baseurl: "/blog"
url: ""
#baseurl: "/blog"
twitter_username: parrotsec
github_username: parrotsec
<nav class="navbar navbar-default navbar-fixed-bottom">
<div class="container footer-content">
Parrot Linux Team Blog
Parrot Team Blog
<p><br />
<span xmlns:dct="" property="dct:title">This blog</span> is written by the <a
xmlns:cc="" href="" property="cc:attributionName"
rel="cc:attributionURL">Parrot Team</a> <br> Copyright © Lorenzo "Palinuro" Faletra, 2019 some rights reserved. <br>
Licensed under a <a rel="license" href="">Creative Commons BY-SA 4.0
International License</a>.
<a rel="license" href=""><img alt="Creative Commons License"
style="border-width:0" src="" /></a></p>
......@@ -48,7 +48,7 @@
<link href="{{ "/css/font-awesome.min.css" | prepend: site.baseurl | prepend: site.url }}" rel="stylesheet">
<link href="" rel="stylesheet">
<link href="" rel="stylesheet">
<link rel="canonical" href="{{ page.url | replace:'index.html','' | prepend: site.baseurl | prepend: site.url }}">
<link rel="alternate" type="application/rss+xml" title="{{ site.title }}" href="{{ "/feed.xml" | prepend: site.baseurl | prepend: site.url }}">
......@@ -27,10 +27,10 @@
<ul class="nav navbar-nav navbar-right">
<li><a href="">Back to home</a></li>
<li><a href="">Community</a></li>
<li><a href="">Documentation</a></li>
<li><a href="">Edit</a></li>
<li><a href="">Back to home</a></li>
<li><a href="">Community</a></li>
<li><a href="">Documentation</a></li>
<li><a href="">Edit</a></li>
</div><!-- /.navbar-collapse -->
......@@ -60,7 +60,7 @@ The desktop-base and parrot-wallpapers also received some love and are updated t
such changes including the new Parrot appearence.
**Note:**The themes and icons are still the same.
**Note:** The themes and icons are still the same.
id: 258
title: Infrastructure Outage
date: 2019-08-01T17:32:40+00:00
author: s1udge
layout: post
permalink: /infrastructure-outage/
- News
Hey guys, on Sunday July 21, 2019, we attempted to migrate the master node from Debian *stretch* to *buster*. During the migration we had a bug with *lxd* which prevented the containers from working properly. We bought a server from [soyoustart]( and waited to set things up. While this was going on we had a a rather large DDoS hitting parts of our torrent service. Initially we tried to just migrate and continue with *lxd* however that didn't work and cost us considerable time.
The following day [Jul 22, 2019](/infrastructure-outage#message-1) I posted to our Telegram communities what information I knew and some things I believed to be accurate, that our server had gone down and our keyserver for the archives was down. Prior to our infrastructure going down we changed the APT archives from **stable** to **rolling** without mentioning it officially and this began to cause problems for people.
Our communication with our userbase was slow and clunky. Changing our infrastructure configuration from *lxd* to *Docker-compose* made things take much longer. Long term however we think it will speed things up and prevent this kind of incident from happening again. We realize that changing domain names might not have been the right answer but we think it was best to make that change instead of waiting for a later time.
Three days later we sent out a second message [Jul 25, 2019](/infrastructure-outage#message-2) describing everything we knew and what we were doing. By this time things for the most part had stabilized.
In summary the things we learned:
1. Have a plan.
Internally there was nothing that would point us in the direction of what to do or how to respond. What our sysadmins did was entirely based off their experiences which although it wasn't bad, we could have done better. The lack of a plan for incident response, and over-reliance on one or two people made things considerably slower both in communication and in execution of recovery.
2. Communicate and respond as a team.
Although we have a rather large team (30+ people) the amount of people actually involved was much smaller and fairly spotty, we simply don't have the pool of sysadmin experience we need. Our poor communication hamstrung efforts to respond and alert users beforehand about what was going on and while the incident occurred. The failure to plan properly for our changes from stable to rolling caused a lot of unnecessary issues which should have been addressed with proper planning and community outreach. Planning as a process is something we will be implementing going forward.
3. Have a backup server and sysadmin training.
Part of this is due to a lack of funding which we hope will be resolved in the near future. Also we really appreciate the help and advice received from the staff at Hack The Box ([HTB](, but we should ensure our sysadmins get some training and familiarity with each part of the infrastructure thus avoiding an over-reliance on one person over another.
# Message 1
Here's the deal right now we in a bit of a bind. One thing has snowballed into another and though we've learned some lessons and will share later, that doesn't help most of you right now.
Currently, the master key server is offline. That is why you can't verify that your keys for the rolling URI's are secure. Unfortunately only one person has the GPG key access needed to sign the dependencies which have not been updated (which is why people are getting the conflicting distribution error or a GPG error if they change their source list to rolling).
All of this happened while we had a server upgrade that went wrong and crashed bringing down most of our core infrastructure. Currently our sysadmins have bought a new server and are bringing our services online as fast as they can. We'll update you when we have more to share.
I'd like to apologize for the lack of communication over everything. I believe we will have everything up and running within the next 12 hours and I hope to have the dependencies issue fixed as soon as possible.
# Message 2
First I'd like to apologise for the downtime. We'd also like to clarify some things that were said before that are not accurate. Our master server went down due to a bug in lxd during an update. We took a bit too long to deploy new hardware, as initially we tried to fix things. However it didn't work and we ended up wasting some time.
While this happened we had a rather large DDoS attack hit some parts of our infrastructure. The DDoS made recovery a little slower, but the outage gave us the chance to do two things we've been planning for a while which is
1. to standardize our infrastructure with docker-compose and other safe-to-share technologies. This allows us to share our infrastructure configuration without exposing critical parts of it, without giving third party access to our servers and enabling a fully transparent and reproducible server configurations.
2. to migrate our domain from to the new one and adding a few changes such as versus the old
The reason for the domain change is because we changed our name and focus from being solely for pentesters (ParrotSec) to pentesting, security, privacy and development (ParrotOS).
As of right now we have migrated our main website(, documentation portal( and the start page ( The forum ( has also been migrated however it is still being worked on.
Other services (gitlab for example) will be migrated at a later date and we'll update you when we have a date.
We'd like to thank the team at HTB ( for their advice and support.
To clarify some things I said in my last message, about a week and a half ago we made some changes in preparation for our migration to Devuan.
Among those changes were migrating users from stable to rolling and rolling-security as we prepare to maintain two versions of Parrot OS: `rolling` which will continue as a rolling release ( and Long Term Support (LTS).
A sizeable chunk of users have had problems migrating to the new archives and we'd like to apologise for not being so clear or upfront about that change.
I misspoke about our key server, it's been online the entire time. The issue, for those having problems with the archive rolling-security, was the key wasn't in the keyserver and thus couldn't be verified.
This has now been fixed, if anyone still has issues please let us know.
The change in archives coupled with the inability to verify the security of them, caused a lot of people to think they had broken dependencies. The issue should be resolved by ensuring you have the proper source URI's and execute either `sudo parrot-upgrade` or `sudo apt update` and `sudo apt full-upgrade`
If you are still having issues after adding the correct source lines to parrot.list and running `sudo apt update` please post a message in either our Telegram main group or our Matrix channel
These are the current URI's you should have in your source file located at `/etc/apt/source.list.d/parrot.list`
deb rolling main contrib non-free
#deb-src rolling main contrib non-free
deb rolling-security main contrib non-free
#deb-src rolling-security main contrib non-free
Communication is key in any group interaction and we will be working on this going forward.
......@@ -2,5 +2,5 @@
font-family: 'Ubuntu';
font-style: normal;
font-weight: 400;
src: local('Ubuntu Regular'), local('Ubuntu-Regular'), url( format('truetype');
src: local('Ubuntu Regular'), local('Ubuntu-Regular'), url( format('truetype');
......@@ -19,7 +19,7 @@ layout: default
{% for post in site.posts %}
<div class="post-box">
<div class="post-title">
<a class="post-title" href="{{post.url | prepend:site.baseurl }}" > {{ post.title }}</a>
<a class="post-title" href="{{post.url }}" > {{ post.title }}</a>
<div class="post-excerpt">
{{ post.content | strip_html | truncatewords:20}}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment