Emmapedia - User contributions [en]

Emmapedia

2023-01-25T13:09:08Z

Emma72718:

= There is no such thing as Emmapedia =

== But, this is how I work: ==

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

== Then: ==
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And if it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.
* Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, '''''DO SPEAK UP'''''. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on.

== You already knew that? ==

Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long, or if 'halfway' proves to be all there is.)

Emmapedia

2023-01-25T13:08:28Z

Emma72718:

= There is no such thing as Emmapedia =

== But, this is how I work: ==

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

== Then: ==
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.
* Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, '''''DO SPEAK UP'''''. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on.

== You already knew that? ==

Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long, or if 'halfway' proves to be all there is.)

Emmapedia

2023-01-16T07:41:07Z

Emma72718:

= There is no such thing as Emmapedia =

== But, this is how I work: ==

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

== Then: ==
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.
* Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, '''''DO SPEAK UP'''''. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on.

== You already knew that? ==

Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long.)

Emmapedia:Privacy policy

2023-01-16T07:20:01Z

Emma72718: Created page with "I'm not collecting anything. Oh wait, your IP address might be in the server logs. But I'm not doing anything with that log and it will rotate after a while. All your secrets are safe on this site because you're not able to tell them here anyway. There might be technical cookies somewhere but no tracking is done, so the site doesn't even need the infamous EU cookie wall."

I'm not collecting anything. Oh wait, your IP address might be in the server logs. But I'm not doing anything with that log and it will rotate after a while. All your secrets are safe on this site because you're not able to tell them here anyway. There might be technical cookies somewhere but no tracking is done, so the site doesn't even need the infamous EU cookie wall.

Emmapedia:General disclaimer

2023-01-16T07:16:29Z

Emma72718: Created page with "I'm not claiming anything here."

I'm not claiming anything here.

Emmapedia:About

2023-01-16T07:14:59Z

Emma72718: Created page with "= Emma Laurijssens van Engelenhoven = ; LinkedIn: : https://www.linkedin.com/in/emmalaurijssens ; Mastodon: : https://mstdn.esp.nl/@elaurijssens ; Address, phone and e-mail: : Sorry, that would be too easy for the bots. Send me a message on Mastodon or LinkedIn."

= Emma Laurijssens van Engelenhoven =

; LinkedIn:
: https://www.linkedin.com/in/emmalaurijssens

; Mastodon:
: https://mstdn.esp.nl/@elaurijssens

; Address, phone and e-mail:
: Sorry, that would be too easy for the bots. Send me a message on Mastodon or LinkedIn.

Emmapedia

2023-01-16T06:52:31Z

Emma72718:

= There is no such thing as Emmapedia =

== But, this is how I work: ==

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

== Then: ==
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.

== You already knew that? ==

Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long.)

Emmapedia

2023-01-16T06:35:19Z

Emma72718:

= There is no such thing as Emmapedia =

== But, this is how I work: ==

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

== Then: ==
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.

== Need more open doors and generalisations? ==

Sorry, I'm still working on that.

Emmapedia

2023-01-16T06:33:38Z

Emma72718:

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.

Emmapedia

2023-01-16T06:20:39Z

Emma72718:

Emmapedia

2023-01-16T06:19:54Z

Emma72718:

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.
* Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2023-01-13T13:59:10Z

Emma72718: /* There is no such thing as Emmapedia */

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2023-01-13T13:31:26Z

Emma72718: /* There is no such thing as Emmapedia */

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2023-01-13T13:21:42Z

Emma72718: /* There is no such thing as Emmapedia */

= There is no such thing as Emmapedia =

But, this is how I work:

* Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your job, you haven't done enough automation.

Then:
* Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
* Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
* Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
* Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
* Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code> and <code>netstat</code> ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
* Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
* Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
* Still no luck? Use your Google-fu. There's very little that cannot be found on Serverfault or StackOverflow.

Emmapedia

2022-08-25T07:05:26Z

Emma72718: Created page with "= There is no such thing as Emmapedia = Try to figure it out for yourself. Useful links: * [https://google.com Google] * [https://stackoverflow.com Stackoverflow] * [https://serverfault.com Serverfault]"

= There is no such thing as Emmapedia =

Try to figure it out for yourself.

Useful links:

* [https://google.com Google]
* [https://stackoverflow.com Stackoverflow]
* [https://serverfault.com Serverfault]

MediaWiki:Mainpage-nstab

2022-08-25T07:04:22Z

Emma72718: Created page with "Emmapedia"

Emmapedia

MediaWiki:Mainpage-description

2022-08-25T07:03:56Z

Emma72718: Created page with "Emmapedia"

Emmapedia

MediaWiki:Mainpage

2022-08-25T07:03:31Z

Emma72718: Created page with "Emmapedia"

Emmapedia