I had to do this after a company ran for 6 months without an admin and with no documentation whatsoever left for others. From when the sysadmin left to when I arrived, most things went to rack and ruin with only some developers doing a little sysadmin on the side. In the end it took nearly the same amount of time as the time that the company was without an admin to find out the information or rebuild what couldn't be salvaged.
I have to say that it gave me a lasting impression of what a company can lose when handover fails.
Luckily, I've also had some good handovers and the best way I've found to do it would be to book the whole week as a workshop. Nothing the outgoing staff member can do is more important than the handover and it can often create a level of goodwill in that you are asking for their assistance and making them realise how important they have been.
However, there are also some rules to the week. Some apply to you - you need to check what you are being told. Anything that starts to look hinky or just plain wrong needs to be constructively challenged. If it still doesn't add up after a challenge and you know they are lying then you need to get them on garden leave as soon as you have the keys and passwords.
My approach for general sysadmin has been to try to understand the systems from the ground up very quickly and I've found it useful to have the following as general headings:
1) Passwords - where they are, how they are kept, what policies are in place? Generally find out how it has been managed in the past. Most important - verify them.
2) Network diagrams - use network scanning and mapping tools to verify what you are finding
3) Infrastructure services - understand the setup for anything important to the infrastructure of the systems. Things like DNS/DHCP/NIS/Kerberos/Pam/LDAP/AD/Certificate Authorities/Identity Management/etc/etc.
4) Storage services - SANs/Makes/models/Where to find support contracts/BACKUPs/Data replications/File stores/etc.
5) Core end user services - File/Print/Core Databases/Core Apps.
6) Cloud services/domain registration accounts/3rd party supplier access
There will always be more to find out but hopefully having a list of what you need can stop your company wasting a lot of time and money in having to rebuild what it can't support.
There is only one word required in response to this - ssl-bump.
Anyone who thinks that realtime ssl communication over HTTPS is secure is not considering the route traffic is taking and whether a MIM attack is in progress. Transparent man in the middle proxy has been available for some time.
That's always assuming that they give it a chance in the first place. Small vendor/open source vs Safe Big Vendor - easy to see where the IT Managers who buy into the big names are safe/good products are going to put their money.
Personally I think its the basis of long term thinking for any company (which is what the BBC is but with different shareholders) - gain market, sell your goods, make profit, support those dependent upon you whom you are dependent upon.
Funnily that could almost sound like a reason for DRM if you believed that DRM would help achieve selling goods - which is why of course companies use it regardless of whether the reasoning to use DRM or not is flawed.
Yes, the BBC uses a lot of open source and I'm sure would relish a world where it was easy to publish media without DRM, however, I don't see any reason, from the BBC heirarchies perspective to actually support the stance you are saying they should take when there is some risk for the BBC in doing it. Yes it might encourage some other companies to not use DRM, equally it might encourage other companies to be extremely restrictive in allowing the BBC to put their media online and isolate the BBC from its viewers (shareholders, license payers, supporters - call them what you will).
You are proposing an argument against the commonly held falacies that Flash and DRM can secure the media and allow it to be resold multiple times. I'm sure the BBC, who have made statements about open formats previously support this, however, making a stance that could damage the institution because the argument against DRM is not been made successfully to those using it is not a reason for the BBC to take the risk and annoy its viewers.
And that works for the license payers who just want to watch content how? By limiting what they can access? Nice way to sink your service and send all your customers to Netflix.
Couldn't they argue that there was self interest involved rather than a fair statement of fact. If you look at old ground and consider the Microsoft litigation regards code being stolen and Novell's (then) indemnity stance against litigation by Microsoft or others on behalf of their paid customers, could it be argued that Novell were using these to safeguard code they owned?
Hmmm - that diary sounds like an interesting account. I'd read commentary from the board who were asked to advise on its use and the technical discussions prior to testing and had heard about the emporer's intervention, however, hadn't heard about the reason for the lack of response.
It doesn't prevent the fact that dropping the bomb and killing so many people - most of whom were not soldiers, at once is pretty horrific. The question becomes simply whether it did prevent long term deaths....and whether it caused Godzilla of course?
My biggest concern is that on the back of this there is Novell's takeover by Attachmate (funded in part by the sell off of patents). Who has them now...?
Have you actually looked at some of the Open Source desktops recently? KDE is now a fantastic desktop which takes the symantic desktop concept forward better than any other (including OSX and Win) and some of the others are very good too in other ways. To be honest, even Gnome 3 isn't terrible now, it's pretty stable but its just too limiting to be a real desktop from what it used to be in Gnome 2, however, compare it with the tablet desktops, are they limiting? Yes they are.
The problem with G3 is stopped trying to be the best desktop and tried to be a rewrite of some bits of G2, it tried to be a more like a tablet desktop where it led who it should be used rather than lettiing users drive it and while its not failing completely at both, the market has moved on and there are better alternatives out there.
What Gnome needs to do is recognise they aren't the best, refocus on what they need to do to make it the best (and some might be simple usagbility tweaks, some might be new ideas and ways of using it, some might be focussing on a specific market), be clear with people that it will be 6 months or a year before their desktop is near what it needs to be.
I actually think the Linux desktop(s) are now stronger than they have ever been - but also more fragmented.
Some of the reason for this with open source projects is that they come out of a user's desire to do things and fill an niche they see so the teams building the solutions believe they know and understand the end users (they are them). Many of the projects are actually started by gifted but none professional programmers.
It doesn't mean that they can't lose touch with the user base or that the project teams cannot become overly arrogant but I appreciate where they are sometimes coming from or where they can be hostile to complaints. We shouldn't forget that the people doing open source development are often doing it as volunteers. The usual response I give to someone who criticises what I've spent a lot of my time and effort doing for nothing is - if you think you can do better go away and do it yourself or instead of complaining try helping.
I think this is quite straightforward. A company can be responsible for the interfaces that are provided to internal data to none-company devices and the data on company devices. Outside of that the responsibility stops with the end user (employee/customer/guest/consultant/whoever) and the company's usage policies should mirror this and breach of these constitutes breach of contract and therefore liability for damages.
All I can give is the benefit of being in similar situations myself.
My first point of call has been to think about the systems you are working on and work out the commonalities. From there I've start to standardise them into documented systems that are version controlled - your wiki is a fine start to this but I've previously found the same issues you have - fragmentation based on the amount of documentation. This approach doesn't prevent you having lots of differences but does help you to keep track of the commonalities. For example:
1) Systems that run X Operating System you keep to a specific patch level - document it and on all different versions you currently have work towards standardising them to your specific system versions.
2) Systems that run X Database System or other systems need Y differences to the build. These start to form a version numbered build of your platforms.
3) Specific application installs.
To be honest, you've started a big project and will probably take some time but in my experience there are not tools to specifically help with this - ITIL based servicedesks, even with change/cmdb capabilities are not good bases for documentation and I've investigated 7 different ones so far including market leaders. However the approach I've highlighted above I'd say is the start down a CMDB route.
Not sure how much development it gets these days but BackupPC looked reasonable but wasn't bomb proof enough for the systems I looked at it for. It primarily uses rsync to copy files (changes only) but then "deduplicates" the rsyncs. It was actually "deduplication" via none lossy compression but in reality they are similar technologies - they both look for repeat data, make a record of the repetion and what is repeated and remove the repetition. It doesn't shrink your primary storage at all - its purely about a duplcated sets of data.
I partially disagree with your statement as (none lossy) compression performs a type of data deduplication - it looks for repeat data, make a record of the repetion and what is repeated and removes the repetition (duplication). The only difference is efficiency of the algorithm for the differing types of "deduplication" and how and when dedup takes place (during data streaming, on static files or on blocks of data). However, because of this similarilty. Likewise, I partially agree as, it is almost a rebranding of "compression" and therefore a buzz word of little sense.
What I will say is that, if Microsoft thinks its product is good then it should stick to its guns, not expect instant success and keep pushing their interface and features. If it drops this then they are admitting they got it wrong AGAIN. I can't see people every buying products from those who keep getting it wrong repeatedly (unless there is a 20 year old legacy product driving the market they they cannot sensibly move away from).
Its a new market for Microsoft and it has to recognise that it has to be the best product for end users, most attractive to developers and carriers and best able to integrate to come out on top. It can't win this by Marketting alone.
The facts are probably that WP was:
a) Late to market
b) Lacking developer support as many had already moved to iPhone or Android or developed mobile skills on these platforms
c) Not allowing hardware manufacturers to best utilise existing hardware by being proscriptive
d) Trying to be different after the market had already led in specific directions (iPhone then Android). Lets face it, it wasn't going to be easy to get in on this without using a similar interface to iPhone or a good weight of device support (Linux)
e) Less than interesting on most of the original hardware
f) Poor Marketting
g) Leaving carriers being carriers - little value add and little gain.
h) Using the names "Microsoft" and "Windows"
Anyone think of any others? I think instead of arguing between posts I think we can just add a big list together, post it to Microsoft and see if they learn any lessons.
The issue is based on what you need in different scenarios and to meet that I can't see anything wrong in doing both writing to syslog and a database.
Why do both? In larger systems the amount of data is difficult to cross reference and analyse as files due to the amount of sources, size of data, tools to visualise it all, etc. Writing syslog data to centralised syslog services that do use database backends to centralise logs and query/report against them are a key tool in these scenarios. Its one of a number of interfaces you have to analyse what is taking place on your systems.
However, I'd rather use the simplest method of getting log information out of a system if I'm going to use it for debugging an odd situation. There are situations where the overhead of writing to a database or a write remote data might fail and cause no debug information to be written. I'd rather a simple logging system locally.
I agree with this but can see why people may think this way. When I was a newbie I had a very different opinion when I started with Linux/Unix. The reality is that for newbies/usr/bin/bin and/opt/product/bin is not, on the face of it, as straightforward as simply a folder called "Program Files". Unfortunately when you look into the Windows filesystem binary files and libraries are often nearly anywhere despite Microsoft's advice, especially with.Net, Java and many other languages. I have to say that in most cases I see developers working on Linux do tend to have the tendency to stick to the filesystem locations as it supplies an appropriate area for most requirements.
I was at a conference last week where the Facebook's malicious URL detection engine, which was stated by a Websense supplier as sourced by Facebook from Websense, was discussed. I remember using Websense years back as a URL filtering engine (which I believe it still is but with an improvement in deep inspection) and can see how Facebook have probably bolted it in so that traffic using redirects from their site get a layer of filtering before redirection from Websense's URL database and from the on the fly categorisation features, however, I can also see why there is still vulnerability. URL blockers, DPI engines and the like, like Websense, are tools that are always in development and are rarely anywhere near 100% accurate, instead, being aimed at giving an acceptable level of accuracy.
To be honest, I can't see that this vulnerability will be anywhere near the top of the list of vulnerabilities in tools like these. I'd be surprised if an unclassified (by the filtering engine) proxy couldn't redirect to wherever was required
Slashdot Mirror
I had to do this after a company ran for 6 months without an admin and with no documentation whatsoever left for others. From when the sysadmin left to when I arrived, most things went to rack and ruin with only some developers doing a little sysadmin on the side. In the end it took nearly the same amount of time as the time that the company was without an admin to find out the information or rebuild what couldn't be salvaged.
I have to say that it gave me a lasting impression of what a company can lose when handover fails.
Luckily, I've also had some good handovers and the best way I've found to do it would be to book the whole week as a workshop. Nothing the outgoing staff member can do is more important than the handover and it can often create a level of goodwill in that you are asking for their assistance and making them realise how important they have been.
However, there are also some rules to the week. Some apply to you - you need to check what you are being told. Anything that starts to look hinky or just plain wrong needs to be constructively challenged. If it still doesn't add up after a challenge and you know they are lying then you need to get them on garden leave as soon as you have the keys and passwords.
My approach for general sysadmin has been to try to understand the systems from the ground up very quickly and I've found it useful to have the following as general headings:
1) Passwords - where they are, how they are kept, what policies are in place? Generally find out how it has been managed in the past. Most important - verify them.
2) Network diagrams - use network scanning and mapping tools to verify what you are finding
3) Infrastructure services - understand the setup for anything important to the infrastructure of the systems. Things like DNS/DHCP/NIS/Kerberos/Pam/LDAP/AD/Certificate Authorities/Identity Management/etc/etc.
4) Storage services - SANs/Makes/models/Where to find support contracts/BACKUPs/Data replications/File stores/etc.
5) Core end user services - File/Print/Core Databases/Core Apps.
6) Cloud services/domain registration accounts/3rd party supplier access
There will always be more to find out but hopefully having a list of what you need can stop your company wasting a lot of time and money in having to rebuild what it can't support.
There is only one word required in response to this - ssl-bump.
Anyone who thinks that realtime ssl communication over HTTPS is secure is not considering the route traffic is taking and whether a MIM attack is in progress.
Transparent man in the middle proxy has been available for some time.
That's always assuming that they give it a chance in the first place. Small vendor/open source vs Safe Big Vendor - easy to see where the IT Managers who buy into the big names are safe/good products are going to put their money.
Only if you can get around secure-boot...
Personally I think its the basis of long term thinking for any company (which is what the BBC is but with different shareholders) - gain market, sell your goods, make profit, support those dependent upon you whom you are dependent upon.
Funnily that could almost sound like a reason for DRM if you believed that DRM would help achieve selling goods - which is why of course companies use it regardless of whether the reasoning to use DRM or not is flawed.
Yes, the BBC uses a lot of open source and I'm sure would relish a world where it was easy to publish media without DRM, however, I don't see any reason, from the BBC heirarchies perspective to actually support the stance you are saying they should take when there is some risk for the BBC in doing it. Yes it might encourage some other companies to not use DRM, equally it might encourage other companies to be extremely restrictive in allowing the BBC to put their media online and isolate the BBC from its viewers (shareholders, license payers, supporters - call them what you will).
You are proposing an argument against the commonly held falacies that Flash and DRM can secure the media and allow it to be resold multiple times. I'm sure the BBC, who have made statements about open formats previously support this, however, making a stance that could damage the institution because the argument against DRM is not been made successfully to those using it is not a reason for the BBC to take the risk and annoy its viewers.
And that works for the license payers who just want to watch content how? By limiting what they can access? Nice way to sink your service and send all your customers to Netflix.
Couldn't they argue that there was self interest involved rather than a fair statement of fact. If you look at old ground and consider the Microsoft litigation regards code being stolen and Novell's (then) indemnity stance against litigation by Microsoft or others on behalf of their paid customers, could it be argued that Novell were using these to safeguard code they owned?
Hmmm - that diary sounds like an interesting account. I'd read commentary from the board who were asked to advise on its use and the technical discussions prior to testing and had heard about the emporer's intervention, however, hadn't heard about the reason for the lack of response.
...and whether it caused Godzilla of course?
It doesn't prevent the fact that dropping the bomb and killing so many people - most of whom were not soldiers, at once is pretty horrific. The question becomes simply whether it did prevent long term deaths.
My biggest concern is that on the back of this there is Novell's takeover by Attachmate (funded in part by the sell off of patents). Who has them now...?
And mostly shipped the waste to countries that will store it and charge you an obscene amount of money for the duration of its half lives...
...like the UK for example.
Still the sound of crickets from the Imperial Palace.
Perhaps that should be the sound of disbelief and complete and utter shock - how many of our people have they killed?!!!?!
Have you actually looked at some of the Open Source desktops recently? KDE is now a fantastic desktop which takes the symantic desktop concept forward better than any other (including OSX and Win) and some of the others are very good too in other ways. To be honest, even Gnome 3 isn't terrible now, it's pretty stable but its just too limiting to be a real desktop from what it used to be in Gnome 2, however, compare it with the tablet desktops, are they limiting? Yes they are.
The problem with G3 is stopped trying to be the best desktop and tried to be a rewrite of some bits of G2, it tried to be a more like a tablet desktop where it led who it should be used rather than lettiing users drive it and while its not failing completely at both, the market has moved on and there are better alternatives out there.
What Gnome needs to do is recognise they aren't the best, refocus on what they need to do to make it the best (and some might be simple usagbility tweaks, some might be new ideas and ways of using it, some might be focussing on a specific market), be clear with people that it will be 6 months or a year before their desktop is near what it needs to be.
I actually think the Linux desktop(s) are now stronger than they have ever been - but also more fragmented.
Some of the reason for this with open source projects is that they come out of a user's desire to do things and fill an niche they see so the teams building the solutions believe they know and understand the end users (they are them). Many of the projects are actually started by gifted but none professional programmers.
It doesn't mean that they can't lose touch with the user base or that the project teams cannot become overly arrogant but I appreciate where they are sometimes coming from or where they can be hostile to complaints. We shouldn't forget that the people doing open source development are often doing it as volunteers. The usual response I give to someone who criticises what I've spent a lot of my time and effort doing for nothing is - if you think you can do better go away and do it yourself or instead of complaining try helping.
Not to mention their access to porn...
I think this is quite straightforward. A company can be responsible for the interfaces that are provided to internal data to none-company devices and the data on company devices. Outside of that the responsibility stops with the end user (employee/customer/guest/consultant/whoever) and the company's usage policies should mirror this and breach of these constitutes breach of contract and therefore liability for damages.
Which is really good for quick docs but gets painful at 20 - 30 GB of images in the docs...
All I can give is the benefit of being in similar situations myself.
My first point of call has been to think about the systems you are working on and work out the commonalities. From there I've start to standardise them into documented systems that are version controlled - your wiki is a fine start to this but I've previously found the same issues you have - fragmentation based on the amount of documentation. This approach doesn't prevent you having lots of differences but does help you to keep track of the commonalities. For example:
1) Systems that run X Operating System you keep to a specific patch level - document it and on all different versions you currently have work towards standardising them to your specific system versions.
2) Systems that run X Database System or other systems need Y differences to the build. These start to form a version numbered build of your platforms.
3) Specific application installs.
To be honest, you've started a big project and will probably take some time but in my experience there are not tools to specifically help with this - ITIL based servicedesks, even with change/cmdb capabilities are not good bases for documentation and I've investigated 7 different ones so far including market leaders. However the approach I've highlighted above I'd say is the start down a CMDB route.
Not sure how much development it gets these days but BackupPC looked reasonable but wasn't bomb proof enough for the systems I looked at it for. It primarily uses rsync to copy files (changes only) but then "deduplicates" the rsyncs. It was actually "deduplication" via none lossy compression but in reality they are similar technologies - they both look for repeat data, make a record of the repetion and what is repeated and remove the repetition. It doesn't shrink your primary storage at all - its purely about a duplcated sets of data.
I partially disagree with your statement as (none lossy) compression performs a type of data deduplication - it looks for repeat data, make a record of the repetion and what is repeated and removes the repetition (duplication). The only difference is efficiency of the algorithm for the differing types of "deduplication" and how and when dedup takes place (during data streaming, on static files or on blocks of data). However, because of this similarilty. Likewise, I partially agree as, it is almost a rebranding of "compression" and therefore a buzz word of little sense.
What I will say is that, if Microsoft thinks its product is good then it should stick to its guns, not expect instant success and keep pushing their interface and features. If it drops this then they are admitting they got it wrong AGAIN. I can't see people every buying products from those who keep getting it wrong repeatedly (unless there is a 20 year old legacy product driving the market they they cannot sensibly move away from).
Its a new market for Microsoft and it has to recognise that it has to be the best product for end users, most attractive to developers and carriers and best able to integrate to come out on top. It can't win this by Marketting alone.
The facts are probably that WP was:
a) Late to market
b) Lacking developer support as many had already moved to iPhone or Android or developed mobile skills on these platforms
c) Not allowing hardware manufacturers to best utilise existing hardware by being proscriptive
d) Trying to be different after the market had already led in specific directions (iPhone then Android). Lets face it, it wasn't going to be easy to get in on this without using a similar interface to iPhone or a good weight of device support (Linux)
e) Less than interesting on most of the original hardware
f) Poor Marketting
g) Leaving carriers being carriers - little value add and little gain.
h) Using the names "Microsoft" and "Windows"
Anyone think of any others? I think instead of arguing between posts I think we can just add a big list together, post it to Microsoft and see if they learn any lessons.
The issue is based on what you need in different scenarios and to meet that I can't see anything wrong in doing both writing to syslog and a database.
Why do both? In larger systems the amount of data is difficult to cross reference and analyse as files due to the amount of sources, size of data, tools to visualise it all, etc. Writing syslog data to centralised syslog services that do use database backends to centralise logs and query/report against them are a key tool in these scenarios. Its one of a number of interfaces you have to analyse what is taking place on your systems.
However, I'd rather use the simplest method of getting log information out of a system if I'm going to use it for debugging an odd situation. There are situations where the overhead of writing to a database or a write remote data might fail and cause no debug information to be written. I'd rather a simple logging system locally.
I agree with this but can see why people may think this way. When I was a newbie I had a very different opinion when I started with Linux/Unix. The reality is that for newbies /usr/bin /bin and /opt/product/bin is not, on the face of it, as straightforward as simply a folder called "Program Files". Unfortunately when you look into the Windows filesystem binary files and libraries are often nearly anywhere despite Microsoft's advice, especially with .Net, Java and many other languages. I have to say that in most cases I see developers working on Linux do tend to have the tendency to stick to the filesystem locations as it supplies an appropriate area for most requirements.
Doesn't that mean that Chromebooks will be able to connect to real computers?
Interesting....
I was at a conference last week where the Facebook's malicious URL detection engine, which was stated by a Websense supplier as sourced by Facebook from Websense, was discussed. I remember using Websense years back as a URL filtering engine (which I believe it still is but with an improvement in deep inspection) and can see how Facebook have probably bolted it in so that traffic using redirects from their site get a layer of filtering before redirection from Websense's URL database and from the on the fly categorisation features, however, I can also see why there is still vulnerability. URL blockers, DPI engines and the like, like Websense, are tools that are always in development and are rarely anywhere near 100% accurate, instead, being aimed at giving an acceptable level of accuracy.
To be honest, I can't see that this vulnerability will be anywhere near the top of the list of vulnerabilities in tools like these. I'd be surprised if an unclassified (by the filtering engine) proxy couldn't redirect to wherever was required