Sudo đầu tiên luôn chậm


8

Lần đầu tiên sudotôi nhập trên máy chủ Ubuntu 14.04 của mình luôn chậm. Dấu nhắc mật khẩu hiển thị ngay lập tức, nhưng sau khi tôi nhấn enter, sẽ mất khoảng 10-15 giây cho đến khi đầu ra được in. Tất cả các lệnh sudo sau khi thực hiện ngay lập tức.

Chạy một cái gì đó như sudo strace -S time -c sudo echo hikhông hiển thị bất cứ điều gì hữu ích trong trường hợp này, vì sudo từ sudo echo hiđã là sudo thứ hai và thực thi nhanh. Nếu một thời gian trôi qua và tôi phải nhập lại mật khẩu trong một phiên chạy, nó sẽ chậm lại.

Tất cả các giải pháp tôi tìm thấy là về việc thêm tên máy chủ của bạn dưới dạng độ phân giải cho 127.0.0.1 trong /etc/hoststệp, điều mà tôi đã không làm được. su rootthực hiện ngay lập tức. Điều duy nhất tôi nhớ là thay đổi trong những ngày qua là netmask của một mạng con mà máy chủ đang định tuyến, cài đặt samba, dnsutils và bind9. Nhưng không có quá trình nào trong số đó đang chạy và vấn đề vẫn còn, trong truy cập vật lý, các phiên ssh cũng như các phiên tmux.

EDIT: Cách tiếp cận mới

Tôi đã thử chạy sudo tcpdump -vvvi any > tcpdump.log trong khi tất cả các NIC bị ngắt kết nối. Nhật ký cho thấy rất nhiều điều sau đây:

18:35:09.453399 IP (tos 0x0, ttl 64, id 49112, offset 0, flags [DF], proto UDP (17), length 76)
    localhost.38498 > localhost.domain: [bad udp cksum 0xfe4b -> 0x1050!] 58546+ SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. (48)
18:35:09.457412 IP (tos 0x0, ttl 64, id 49113, offset 0, flags [none], proto UDP (17), length 76)
    localhost.domain > localhost.38498: [bad udp cksum 0xfe4b -> 0x8fcd!] 58546 ServFail q: SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. 0/0/0 (48)

Các mục tương tự xuất hiện với tcp instad của udp. Tôi đã thay thế tên miền của trường đại học của chúng tôi bằng OURLOCALDOMAIN.

Bây giờ tôi nghĩ kerberos có thể có liên quan đến nó, nhưng tôi đã xóa /etc/krb5.conf và khởi động lại, vẫn không thay đổi. Dường như với tôi, máy chủ cố gắng xác nhận chính nó trên một máy chủ kerberos trung tâm từ mạng lưới trường đại học của chúng tôi. Tôi biết rằng một số năm trước, IP này đã được đăng ký cho một máy chủ chạy samba cho sự khởi hành của chúng tôi. Có thể có mối liên hệ? Tôi đã thay đổi tên máy chủ của mình thành tên được sử dụng trước đó, không thay đổi hành vi sudo. Lmwangi gợi ý vài điều về PAM, mà tôi có ít kiến ​​thức về nó, vì vậy tôi không biết làm thế nào để tiếp cận điều này. Tôi cũng nhớ tôi đã chuyển từ Heimdal Kerberos sang MIT Kerberos khi cài đặt samba, vì tôi gặp rắc rối trong quá trình cài đặt samba. Tôi cũng sẽ thử các ý tưởng từ các bình luận trong những ngày tiếp theo, nhưng tôi sẽ đi du lịch trong một vài ngày để có thể mất một chút thời gian.

EDIT 2: Đã giải quyết

Có một mục dns-search di sản trong /etc/network/interfacesđó làm rối tung mọi thứ. Tôi cảm thấy rất ngu ngốc. Tất cả mọi thứ hoạt động bây giờ.


1
Tạm thời thiết lập bit set-uid stracesẽ cho phép bạn chạy nó mà không cần đầu tiên sudo. Nó cũng có thể giúp sử dụng -o <file>tùy chọn để lưu đầu ra vào một tệp để phân tích.
garethTheRed 04/11 '

1
Đó là một. Sau đó làm theo nó sudo -kđể loại bỏ thông tin lưu trữ của bạn. Tôi thấy strace -Tro sudo.log sudo echo hihữu ích vì cột cuối cùng hiển thị thời gian trong mỗi cuộc gọi. grepcho unamesocketnhư là một khởi đầu.
garethTheRed

1
5,005153 giây là từ -rtùy chọn (có thể nên xóa). Bắt đầu bằng cách tìm kiếm các cuộc gọi dài từ -Ttùy chọn - chúng là những cuộc gọi trong <>- 0,000097 giây trong trường hợp của bạn.
garethTheRed

1
Bạn đã kiểm tra ps, top và tất cả các tệp nhật ký hệ thống trong sự kiện có điều gì khác xảy ra để gây ra sự chậm chạp chưa?
mdpc

1
Bạn có thể gửi cấu hình pam của bạn? stracecuối cùng sẽ đưa bạn đến đó nhưng đây có lẽ là vấn đề cấu hình cấp cao hơn. Hầu hết các lần tạm dừng dài trong quá trình xác thực là do không truy cập được máy chủ từ xa và phải chờ thời gian chờ. Có thể là thay đổi mạng con đặt máy chủ xác thực trên một mạng con khác như mạng con này. sudotạm thời lưu một bản ghi thành công auth bên dưới, /varvì vậy đây có thể là lý do tại sao các yêu cầu tiếp theo đi qua ngay lập tức.
Bratchley

Câu trả lời:


2

Tôi nghi ngờ rằng hộp của bạn đang cố liên hệ với dịch vụ xác thực bên ngoài (nghĩ về NIS / LDAP) bằng PAM ...

Nếu tôi hiểu đúng về PAM, bạn sẽ không thể thấy tra cứu PAM trong các cuộc gọi của bạn. Tôi khuyên bạn nên chạy tshark / tcpdump và xem liệu bạn có thể tương quan lưu lượng truy cập mạng cụ thể với các nỗ lực sudo của mình không. Nghi ngờ ở đây sẽ là tra cứu DNS & | Các cuộc gọi LDAP.

tcpdump -i eth0 -w network.pcap -s0 -Av

Nếu bạn tìm ra nguyên nhân gây ra tra cứu, hãy tìm hiểu mô-đun PAM có liên quan để chỉnh sửa và khắc phục sự cố. Ngoài ra, nếu đó là tra cứu DNS, chỉ cần thêm mục / etc / hosts để giả mạo tên và chuyển hướng đến localhost. Điều này sẽ làm cho sudo của bạn nhanh vì việc tra cứu sẽ nhanh và sẽ chuyển hướng đến localhost và giao dịch mạng sẽ thất bại nhanh chóng vì không có gì nghe trên localhost ...


Bây giờ điều này dường như đi theo một hướng tốt. Tôi có rất nhiều cuộc gọi "bad udp cksum" và "bad tcp cksum" trong nhật ký của mình. Quá dài để đăng trong một bình luận vì vậy tôi sẽ cập nhật OP trong một giây.
zerweck
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.