I'm sure I've posted this before, but repetition is the most sincere form of .... something deep and meaningful.
Want to see what's eating your disk in a particular file-system ?
Try: -
du -hs * | sort -h
against, say, /home to see who is eating your disk, especially in terms of specific user's home directories etc.
Thursday, 23 January 2020
Wednesday, 22 January 2020
Sigh, Jenkins, I was holding it wrong ...
I've created a Jenkins Pipeline that clones a GitHub repository and ... SHOULD ... execute a bunch o' instructions in a Jenkinsfile in the top-level of the repo ....
SHOULD being the operative word ...
The Pipeline runs, clones the repo, even showing up the most recent Commit message ... and then reports: -
Finished: SUCCESS
What was I doing wrong ?
Yeah, you guessed it ...
When I created the Pipeline, I neglected to choose Pipeline script from SCM, which allows me to specify the Script Path as Jenkinsfile
Which meant that there was NOTHING for the Pipeline to do, apart from clone the GitHub repo ....
SHOULD being the operative word ...
The Pipeline runs, clones the repo, even showing up the most recent Commit message ... and then reports: -
Finished: SUCCESS
What was I doing wrong ?
Yeah, you guessed it ...
When I created the Pipeline, I neglected to choose Pipeline script from SCM, which allows me to specify the Script Path as Jenkinsfile
Which meant that there was NOTHING for the Pipeline to do, apart from clone the GitHub repo ....
Friday, 17 January 2020
Run Linux on IBM Z Docker Containers Inside z/OS
Whilst this isn't upon which I'm currently working, it's definitely of interest and relevance: -
Everybody knows that Linux* runs on IBM Z*, but what if you could build a hybrid workload consisting of native z/OS software and Linux on Z software, both running in the same z/OS* image?
Starting from z/OS V2R4, with an exciting new feature named IBM z/OS Container Extensions (zCX), you have a new way to run Linux on IBM Z Docker containers in direct support of z/OS workloads on the same z/OS system. It builds much more flexibility into operations on IBM Z by modernizing and extending z/OS applications.
“With zCX, customers will be able to access the most recent development tools and processes available in Linux on the Z ecosystem, giving developers the flexibility to build new, cloud-native containerized apps and deploy them on z/OS without requiring Linux or a Linux partition,” says Ross Mauri, general manager for IBM (ibm.co/2W04VWW).
See the zCX website (ibm.co/2JaDzWe) if you are interested in more details.
Run Linux on IBM Z Docker Containers Inside z/OS
Everybody knows that Linux* runs on IBM Z*, but what if you could build a hybrid workload consisting of native z/OS software and Linux on Z software, both running in the same z/OS* image?
Starting from z/OS V2R4, with an exciting new feature named IBM z/OS Container Extensions (zCX), you have a new way to run Linux on IBM Z Docker containers in direct support of z/OS workloads on the same z/OS system. It builds much more flexibility into operations on IBM Z by modernizing and extending z/OS applications.
“With zCX, customers will be able to access the most recent development tools and processes available in Linux on the Z ecosystem, giving developers the flexibility to build new, cloud-native containerized apps and deploy them on z/OS without requiring Linux or a Linux partition,” says Ross Mauri, general manager for IBM (ibm.co/2W04VWW).
See the zCX website (ibm.co/2JaDzWe) if you are interested in more details.
Run Linux on IBM Z Docker Containers Inside z/OS
Tuesday, 14 January 2020
docker create - or ... one learns something every day ....
I was looking for a simple way to "peer" inside a newly-built Docker image, without actually starting a container from that image ...
Specifically, I wanted to look at the content of a configuration file - /etc/ssh/sshd_config - to check some security settings.
Thankfully, the internet had the answer - as per usual
Extract file from docker image?
and this worked for me: -
Use the docker create command to create a container without actually creating (instantiating) a container
docker create debian:jessie
Specifically, I wanted to look at the content of a configuration file - /etc/ssh/sshd_config - to check some security settings.
Thankfully, the internet had the answer - as per usual
Extract file from docker image?
and this worked for me: -
Use the docker create command to create a container without actually creating (instantiating) a container
docker create debian:jessie
This returns the ID of the created container: -
7233e5c0df37bd460cc4d13b98f1f0b4d2d04677ea3356ad178af3a4af6484e5
Use the container ID to copy the required file to, say, /tmp
docker cp 7233e5c0df37bd460cc4d13b98f1f0b4d2d04677ea3356ad178af3a4af6484e5:/etc/ssh/sshd_config /tmp
Check out the copied file
cat /tmp/sshd_config
Delete the container
docker rm 7233e5c0df37bd460cc4d13b98f1f0b4d2d04677ea3356ad178af3a4af6484e5
Job done!
Obviously, I could've been even more elegant: -
export CONTAINER=`docker create debian:jessie`
docker cp $CONTAINER:/etc/ssh/sshd_config /tmp
cat /tmp/sshd_config
docker rm $CONTAINER
Nice !
Monday, 13 January 2020
Book Review - Penetration Testing - A guide for business and IT managers
Another book review on behalf of the British Computer Society, who kindly provided me with a hard-copy of this book: -
Penetration Testing - A guide for business and IT managers
This book is written as a series of standalone chapters, each authored by one of a series of experienced practitioners, and can be consumed in whole or in part. Each chapter can then be used as a source of reference for a particular aspect of a penetration testing activity.
As the title suggests, the book is intended to be a guide for the leadership team of any business and, as such, uses brevity and clarity to facilitate understanding. It's not intended to be a detailed reference guide for a penetration tester - other materials exist to meet this requirement - but it does provide a useful insight into the wider discipline of security and penetration testing.
It is logically organised, introducing the subject of penetration testing before digging into the rules and regulations surrounding a project, in terms of the regulatory framework and contractual obligations.
This latter topic is crucial, in terms of ensuring that the scope of the testing activity is well-defined and that the testers are commercially and legally covered for their planned activities.
In later chapters, more attention is paid to scoping testing activities, in terms of ensuring that the organisation is aligned with the expected outcomes, and that the test coverage is appropriately sized and scaled.
As a former software services professional, I also appreciated the compare/contrast between "best" and "good" practices, especially as perfection is often the enemy of the good, to misquote a common phrase. In other words, whilst "best" practice may be desirable, "good enough" is perhaps a more realistic and timely aiming point, especially as financial budgets and timescales are often tight.
As one would expect, there is focus upon the tooling that a tester would use, including Burpsuite, nmap, Nessus and Wireshark, whilst also focusing on community-driven offerings such as Open Web Application Security Project (OWASP). Again, these are covered at a reasonably high-level, and the authors would expect testers to be aware of individual tools, in terms of fit, coverage, support and licensing models.
Towards the end of the book, attention is paid to test reporting and, equally importantly, the action planning that needs to follow on from testing, as well as the requirement to schedule a follow-up testing activity to check the actual results against the planned remediations.
In conclusion, whilst the audience for this book is clearly intended to be project or organisation leaders, it's brief enough to serve as a useful introduction to the practice of penetration testing, and would serve as a grounding for anyone intending to develop their career into this subject domain.
Therefore, I'm comfortable in recommending this book, and would rate it 9/10 for context, brevity and completeness.
Penetration Testing - A guide for business and IT managers
This book is written as a series of standalone chapters, each authored by one of a series of experienced practitioners, and can be consumed in whole or in part. Each chapter can then be used as a source of reference for a particular aspect of a penetration testing activity.
As the title suggests, the book is intended to be a guide for the leadership team of any business and, as such, uses brevity and clarity to facilitate understanding. It's not intended to be a detailed reference guide for a penetration tester - other materials exist to meet this requirement - but it does provide a useful insight into the wider discipline of security and penetration testing.
It is logically organised, introducing the subject of penetration testing before digging into the rules and regulations surrounding a project, in terms of the regulatory framework and contractual obligations.
This latter topic is crucial, in terms of ensuring that the scope of the testing activity is well-defined and that the testers are commercially and legally covered for their planned activities.
In later chapters, more attention is paid to scoping testing activities, in terms of ensuring that the organisation is aligned with the expected outcomes, and that the test coverage is appropriately sized and scaled.
As a former software services professional, I also appreciated the compare/contrast between "best" and "good" practices, especially as perfection is often the enemy of the good, to misquote a common phrase. In other words, whilst "best" practice may be desirable, "good enough" is perhaps a more realistic and timely aiming point, especially as financial budgets and timescales are often tight.
As one would expect, there is focus upon the tooling that a tester would use, including Burpsuite, nmap, Nessus and Wireshark, whilst also focusing on community-driven offerings such as Open Web Application Security Project (OWASP). Again, these are covered at a reasonably high-level, and the authors would expect testers to be aware of individual tools, in terms of fit, coverage, support and licensing models.
Towards the end of the book, attention is paid to test reporting and, equally importantly, the action planning that needs to follow on from testing, as well as the requirement to schedule a follow-up testing activity to check the actual results against the planned remediations.
In conclusion, whilst the audience for this book is clearly intended to be project or organisation leaders, it's brief enough to serve as a useful introduction to the practice of penetration testing, and would serve as a grounding for anyone intending to develop their career into this subject domain.
Therefore, I'm comfortable in recommending this book, and would rate it 9/10 for context, brevity and completeness.
Friday, 10 January 2020
Red Hat OpenShift, IBM Cloud Paks and more facilitate digital transformation.
This is, in part, upon which I've been working this past year or so
Red Hat OpenShift, IBM Cloud Paks and more facilitate digital transformation
Definitely worth a read, especially to provide context about RH OCP, Cloud Paks and, close to my heart, Hyper Protect Services.
Red Hat OpenShift, IBM Cloud Paks and more facilitate digital transformation
Definitely worth a read, especially to provide context about RH OCP, Cloud Paks and, close to my heart, Hyper Protect Services.
Monday, 6 January 2020
More from Julia Evans - Your Linux Toolbox
I've mentioned Julia Evans several times before, but she's again wowed me with another rather useful set of enablement materials: -
Your Linux Toolbox
which is available as hard and soft copy.
At time of writing, she's also offering a 20% discount !
Check out Julia on Twitter - @b0rk - and enjoy !
Your Linux Toolbox
which is available as hard and soft copy.
At time of writing, she's also offering a 20% discount !
Check out Julia on Twitter - @b0rk - and enjoy !
Subscribe to:
Posts (Atom)