hi,
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
On 01/23/2013 05:23 AM, Adekoya Adekunle wrote:
hi,
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
http://www.linuxquestions.org/questions/red-hat-31/how-to-change-the-default...
http://osxdaily.com/2011/03/07/change-set-the-default-crontab-editor/
http://www.linuxforum.com/threads/452-Set-your-default-editor-for-things-lik...
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
hi,
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
From a terminal window:
su gedit /etc/crontab &
I do it all the time. I suppose there is a one line variant with sudo, but I tend to have a root terminal open for lots of different things.
Robert Moskowitz wrote:
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
From a terminal window:
su gedit /etc/crontab &
I do it all the time. I suppose there is a one line variant with sudo, but I tend to have a root terminal open for lots of different things.
Bad idea. Very much depreciated. You should edit crontab using -e [1], and sudoers with visudo.
1] to use a different editor, from the man pages: ENVIRONMENT
VISUAL Invoked by visudo as the editor to use
EDITOR Used by visudo if VISUAL is not set
Using the correct tool invokes syntax checking *before* it's saved. If you don't have root password, you could seriously be up the creek if you make a typo in sudoers....
mark
On 01/23/2013 01:39 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
From a terminal window:
su gedit /etc/crontab &
I do it all the time. I suppose there is a one line variant with sudo, but I tend to have a root terminal open for lots of different things.
Bad idea. Very much depreciated. You should edit crontab using -e [1], and sudoers with visudo.
1] to use a different editor, from the man pages: ENVIRONMENT
VISUAL Invoked by visudo as the editor to use EDITOR Used by visudo if VISUAL is not set
Using the correct tool invokes syntax checking *before* it's saved. If you don't have root password, you could seriously be up the creek if you make a typo in sudoers....
Serious typos abound. The most serious one I did was to fstab once upon a time.
I don't use sudo. If I need root changes, I better have the root password to use su. If I don't have the root password, then it is either not my system to change, or I have a serious problem indeed.
On Thu, Jan 24, 2013 at 7:52 AM, Robert Moskowitz rgm@htt-consult.com wrote:
On 01/23/2013 01:39 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
From a terminal window:
su gedit /etc/crontab &
I do it all the time. I suppose there is a one line variant with sudo, but I tend to have a root terminal open for lots of different things.
Bad idea. Very much depreciated. You should edit crontab using -e [1], and sudoers with visudo.
1] to use a different editor, from the man pages: ENVIRONMENT
VISUAL Invoked by visudo as the editor to use EDITOR Used by visudo if VISUAL is not set
Using the correct tool invokes syntax checking *before* it's saved. If you don't have root password, you could seriously be up the creek if you make a typo in sudoers....
Serious typos abound. The most serious one I did was to fstab once upon a time.
I don't use sudo. If I need root changes, I better have the root password to use su. If I don't have the root password, then it is either not my system to change, or I have a serious problem indeed.
That's fine unless you have 100s of machines to administer. If you have 100 machines do you a) set all the root passwords to the same, or b) maintain a manual file of logins.
Cheers,
Cliff
Cliff Pratt wrote:
On Thu, Jan 24, 2013 at 7:52 AM, Robert Moskowitz rgm@htt-consult.com wrote:
On 01/23/2013 01:39 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
From a terminal window:
su gedit /etc/crontab &
I do it all the time. I suppose there is a one line variant with sudo, but I tend to have a root terminal open for lots of different
things.
Bad idea. Very much depreciated. You should edit crontab using -e [1], and sudoers with visudo.
1] to use a different editor, from the man pages: ENVIRONMENT
VISUAL Invoked by visudo as the editor to use EDITOR Used by visudo if VISUAL is not set
Using the correct tool invokes syntax checking *before* it's saved. If you don't have root password, you could seriously be up the creek if you make a typo in sudoers....
Serious typos abound. The most serious one I did was to fstab once upon a time.
I don't use sudo. If I need root changes, I better have the root password to use su. If I don't have the root password, then it is either not my system to change, or I have a serious problem indeed.
Some environments prefer you use sudo, even if it's sudo -s, so that what you do is logged.
That's fine unless you have 100s of machines to administer. If you have 100 machines do you a) set all the root passwords to the same, or b) maintain a manual file of logins.
Or even a few... if the one you screw up on is a production server, or one that the developers are going nuts on, or is about to be used for a presentation to upper management, and you can't take it down to single user....
mark
On 01/23/2013 03:53 PM, Cliff Pratt wrote:
On Thu, Jan 24, 2013 at 7:52 AM, Robert Moskowitz rgm@htt-consult.com wrote:
On 01/23/2013 01:39 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
How can I open crontab with gedit any any other editor ?
i want to edit my cron jobs with other editors beside vi.
From a terminal window:
su gedit /etc/crontab &
I do it all the time. I suppose there is a one line variant with sudo, but I tend to have a root terminal open for lots of different things.
Bad idea. Very much depreciated. You should edit crontab using -e [1], and sudoers with visudo.
1] to use a different editor, from the man pages: ENVIRONMENT
VISUAL Invoked by visudo as the editor to use EDITOR Used by visudo if VISUAL is not set
Using the correct tool invokes syntax checking *before* it's saved. If you don't have root password, you could seriously be up the creek if you make a typo in sudoers....
Serious typos abound. The most serious one I did was to fstab once upon a time.
I don't use sudo. If I need root changes, I better have the root password to use su. If I don't have the root password, then it is either not my system to change, or I have a serious problem indeed.
That's fine unless you have 100s of machines to administer. If you have 100 machines do you a) set all the root passwords to the same, or b) maintain a manual file of logins.
I am fortunate this way; this is not my day job. But I do not have an IT group to manage most of my systems I use to support my day job, so I am it. Thus I lean on those of you that have this as a day job to figure out what I have not yet figured out. I do try and help with what I know, but most of it is theory on things which are still a few years out. What many of you are working with in security services, I was working on developing back when they were developed. Like digital certs and PKI infrastructure as an example. Today my efforts are in what is called 'the Internet Of Things' and 'Home Area Networks' and 'Medical Body Area Networks'. Mostly those little tiny things that most are not bothering to secure.
Thanks for all the help you people provide me. Hopefully I will be helping to create technologies that will continue to provide you all with livelyhoods :)
Oh, years ago I wrote about the importance of writing down important ids and passwords and putting them in a firebox with someone important knowing where it is. There are lots of disaster stories out their, small and large, where the people that knew these were lost and data was or almost lost as well. And I was talking to Tatu Ylonen, the creator of SSH (when he was a student in Helsinki), back in November on the disaster of SSH accounts at many large companies. He has found banks with thousands of SSH accounts that no one knows whose they are or how to clean them up. He is working on a set of tools to help out on this.
Robert Moskowitz wrote:
On 01/23/2013 03:53 PM, Cliff Pratt wrote:
On Thu, Jan 24, 2013 at 7:52 AM, Robert Moskowitz rgm@htt-consult.com wrote:
On 01/23/2013 01:39 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
<snip>
I don't use sudo. If I need root changes, I better have the root password to use su. If I don't have the root password, then it is either not my system to change, or I have a serious problem indeed.
That's fine unless you have 100s of machines to administer. If you have 100 machines do you a) set all the root passwords to the same, or b) maintain a manual file of logins.
I am fortunate this way; this is not my day job. But I do not have an IT group to manage most of my systems I use to support my day job, so I am it. Thus I lean on those of you that have this as a day job to figure out what I have not yet figured out. I do try and help with what I know, but most of it is theory on things which are still a few years out. What many of you are working with in security services, I was working on developing back when they were developed. Like digital certs and PKI infrastructure as an example. Today my efforts are in what is called 'the Internet Of Things' and 'Home Area Networks' and 'Medical Body Area Networks'. Mostly those little tiny things that most are not bothering to secure.
Oh, Ghu, NO!!! You're the one responsible for that horror.
You think I exaggerate? Consider the "smart house" when it blue screens. And "not secured"? So that some 16 yr old script kiddie can defrost your refrigerator when you're not home, full of food? Or turn your hot water heater to "lobster boil temp"?
Note that it was just a few years ago that some moron in Britrail? One of the privatized British rail services? had their centralized contol on the Net, and some 16 yr old idiot broke it, changed a switch setting, and a train derailled with injuries, maybe some fatalities.
So I am *NOT* happy with that idea....
Thanks for all the help you people provide me. Hopefully I will be helping to create technologies that will continue to provide you all with livelyhoods :)
Great. I get to look forward to upgrading the security on your toilet....*
Oh, years ago I wrote about the importance of writing down important ids and passwords and putting them in a firebox with someone important knowing where it is. There are lots of disaster stories out their, small and large, where the people that knew these were lost and data was or almost lost as well. And I was talking to Tatu Ylonen, the creator of SSH (when he was a student in Helsinki), back in November on the disaster of SSH accounts at many large companies. He has found banks with thousands of SSH accounts that no one knows whose they are or how to clean them up. He is working on a set of tools to help out on this.
What, you're forgetting, was it LA or SF, that just had that happen very publicly, when that admin left and didn't want to tell the admins the passwords, a couple of years ago?
No. A manager should *always* have the written passwords, somewhere, if you quit, or get hit by a car coming back from lunch....
mark
On 01/24/2013 10:34 AM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 01/23/2013 03:53 PM, Cliff Pratt wrote:
On Thu, Jan 24, 2013 at 7:52 AM, Robert Moskowitz rgm@htt-consult.com wrote:
On 01/23/2013 01:39 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 01/23/2013 06:23 AM, Adekoya Adekunle wrote:
<snip> >>> I don't use sudo. If I need root changes, I better have the root >>> password to use su. If I don't have the root password, then it is >>> either not my system to change, or I have a serious problem indeed. >>> >> That's fine unless you have 100s of machines to administer. If you >> have 100 machines do you a) set all the root passwords to the same, or >> b) maintain a manual file of logins. > I am fortunate this way; this is not my day job. But I do not have an > IT group to manage most of my systems I use to support my day job, so I > am it. Thus I lean on those of you that have this as a day job to > figure out what I have not yet figured out. I do try and help with what > I know, but most of it is theory on things which are still a few years > out. What many of you are working with in security services, I was > working on developing back when they were developed. Like digital certs > and PKI infrastructure as an example. Today my efforts are in what is > called 'the Internet Of Things' and 'Home Area Networks' and 'Medical > Body Area Networks'. Mostly those little tiny things that most are not > bothering to secure. Oh, Ghu, NO!!! You're the one responsible for that horror.
You think I exaggerate? Consider the "smart house" when it blue screens. And "not secured"? So that some 16 yr old script kiddie can defrost your refrigerator when you're not home, full of food? Or turn your hot water heater to "lobster boil temp"?
Note, I am the one trying to fix this disaster. Check out IEEE 802.15.9. I am privy to attacks that you do not even want to know about. Be afraid. Be VERY afraid.
Note that it was just a few years ago that some moron in Britrail? One of the privatized British rail services? had their centralized contol on the Net, and some 16 yr old idiot broke it, changed a switch setting, and a train derailled with injuries, maybe some fatalities.
Why I am working with IEEE 802.15.4p, Postive Train Control. Which is a federal law and the proprietary solutions getting deployed to meet the 2014 date are badddddd.
So I am *NOT* happy with that idea....
Thanks for all the help you people provide me. Hopefully I will be helping to create technologies that will continue to provide you all with livelyhoods :)
Great. I get to look forward to upgrading the security on your toilet....*
YEP! Already an issue in asia.
Oh, years ago I wrote about the importance of writing down important ids and passwords and putting them in a firebox with someone important knowing where it is. There are lots of disaster stories out their, small and large, where the people that knew these were lost and data was or almost lost as well. And I was talking to Tatu Ylonen, the creator of SSH (when he was a student in Helsinki), back in November on the disaster of SSH accounts at many large companies. He has found banks with thousands of SSH accounts that no one knows whose they are or how to clean them up. He is working on a set of tools to help out on this.
What, you're forgetting, was it LA or SF, that just had that happen very publicly, when that admin left and didn't want to tell the admins the passwords, a couple of years ago?
No. A manager should *always* have the written passwords, somewhere, if you quit, or get hit by a car coming back from lunch....
And how many managers don't?
Yeah, lifetime employment....
On 2013-01-24, m.roth@5-cent.us m.roth@5-cent.us wrote:
What, you're forgetting, was it LA or SF, that just had that happen very publicly, when that admin left and didn't want to tell the admins the passwords, a couple of years ago?
It was San Francisco. Here are some stories on it; I'm sure DDG can find others:
https://www.pcworld.com/article/148824/san_francisco_network.html http://www.sfgate.com/bayarea/article/S-F-officials-locked-out-of-computer-n...
No. A manager should *always* have the written passwords, somewhere, if you quit, or get hit by a car coming back from lunch....
Agreed, but you need to a) impress on your manager that he should not break into the passwords unless you really have quit or been hit by a bus, and b) trust your manager not to do a). If you don't really trust him not to do something stupid with the password list, hide it somewhere else and tell a trusted colleague where it is.
--keith
On Fri, Jan 25, 2013 at 4:34 AM, m.roth@5-cent.us wrote:
What, you're forgetting, was it LA or SF, that just had that happen very publicly, when that admin left and didn't want to tell the admins the passwords, a couple of years ago?
No. A manager should *always* have the written passwords, somewhere, if you quit, or get hit by a car coming back from lunch....
I used to think that, but a password is almost always recoverable, on more or less any Linux system. It may be inconvenient and time consuming, even expensive for one reason or another, but a password is almost always recoverable or resettable so I've stopped worrying about making my passwords 100% safe from destruction or loss. However they should be as close to 100% secure from being stolen as possible.
Cheers,
Cliff
On 2013-01-25, Cliff Pratt enkiduonthenet@gmail.com wrote:
I used to think that, but a password is almost always recoverable, on more or less any Linux system.
In the San Francisco case, the passwords in question were for Cisco routers and other networking equipment. Those are probably much harder to recover/reset, and much more inconvenient to do. I believe that getting someone in to reset the passwords would have been a few thousand dollars and taken the entire city government network down for at least a day, possibly longer. (At least that's what we were told at the time.)
In addition, consider this not-terribly-likely scenario (though probably no less likely than me getting hit by a bus): I get mugged, my phone with my Keypass file on it is stolen, and I'm left unconscious. In this case my manager probably wants the passwords changed as quickly as possible, just in case the thief wants to try to crack my Keepass encryption and crack our servers. Given a choice between having to hire someone incredibly expensive to reset all the passwords right away (and hope that he's gotten all of them!) (including the passwords for the non-linux boxes) and having the passwords right in front of him, I am guessing that most managers would choose the latter.
One compromise solution would be to share the Keepass file with your manager, and keep the keyfile and/or passphrase with someone trusted (either the manager or someone else). This way there is an independent record of the passwords but they are still encrypted. If the password file is on a USB stick, then it's also not on the network and at risk of remote copying.
Think of it as RAID1 for your passwords. Sysadmins love redundancy! :)
--keith